Re: [O] Export to google docs spreadsheet
On Monday, 16 Mar 2015 at 22:10, Marcelo de Moraes Serpa wrote: > Hi all, > > Is there a way to export an orgmode spreadsheet to a format that can be > imported by google docs? M-x org-table-export RET will export to TSV or CSV which you can read into any spreadsheet program although I have no idea what google docs may expect or allow. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-895-g375c83
Re: [O] Citation syntax: a revised proposal
Hi all, Richard Lawrence writes: > Hi Aaron and all, > > Richard Lawrence writes: > >> I'll take some time this weekend to see if I can wire this together with >> the Elisp Aaron wrote for the Org exporter side. > > I've had some success with this. I would not say that my efforts are > complete yet, but I thought I should send an update to let everyone > know. I've published a branch here: > > https://github.com/wyleyr/org-mode > > which derives from Aaron's wip-cite-awe branch. Basically, what I've > been able to do so far is process citations in a document via > org-citeproc, using a bibtex database file, then insert the processed > citations and bibliography in the document during export. (In theory, > this should work with org-bibtex too, though I think I may have > introduced a bug...the library is not producing well-formed bibtex from > org-bibtex entries for me at the moment.) It works pretty slick, at > least for the simple cases I've tested. > [ ... ] I have been following this thread from (quite) some distance as I am very interested in more general citation support from orgmode. Please allow some basic questions: 1. For the LaTeX user This change means that the LaTeX user can use org syntax for citations rather than bare LaTeX (or links of some sort)? And this org syntax could then (I guess is the future) be extended with additional link-like functionality (maybe similar to org-ref)? 2. The non-LaTeX exports These are all treated the same and will contain just text, that is produced to mimic LaTeX's output to some extent? I think I read some question about e.g. having zotero handling the citations in the odt export. Are there plans for such thing? 3. The database As I understand the database currently is either bibtex or org? But that list could in principle be extended to zotero ... ? And any other database X (zotero ...) would need translations X -> bibtex to make the LaTeX export work with it as well? 4. Example Could you post one of your examples? I'd love to see the prototype in action to have a proper picture of this. Thanks to all working on this! Andreas
[O] [proposal] enhancement of Org-Mode tables and related features
Hi 1) Org-Mode tables currently do not have an easy way to format each cell individually. For regular text, I can select a region and do M-x fill-paragraph and that works fine, but for Org-Mode tables, I cannot do that. Yes, I know about M-x org-table-wrap-region , I have tried to use it for a few hours, read the manuals, read pages that talked about it and I was unable to get it working. 2) As a user, I'd also really appreciate M-x RET to work better. Currently if I go somewhere on a line and run that, the text until the end of that line is deleted and prepended to the start of the next line. So, by doing that, I solved the length of the text on the current line, but now I moved the problem to the next line, where the text is again longer than it should be. 3) I've used C-c ` a few times and tried to make sense of it. As far as I can tell it only works for one line. For me personally, in order for C-c ` to be useful, I would expect it to work on the entire table cell, not just one line in the table cell. These are my suggestions for improvements. I welcome feedback on them. Thanks for taking the time to read this
[O] [proposal] better documentation around syntax highlighting Org-Mode code blocks when exporting to LaTeX
Hi, While writing technical documents, as a programmer and an Org-Mode user, for me it's important to have ways to syntax highlight code blocks when exporting them to LaTeX. While I am aware of the customizations that need to be done to Org-Mode's configuration in order to get that to work, in particular customizing these variables(see [1] for details): * org-latex-listings * org-latex-custom-lang-environments * org-latex-minted-options and having tried them, I got this working for one document, but it really felt like a lot of trial-and-error and a lot of room for error on my side as a user. Although this is Org-Mode and it is supposed to be very customizable (like Emacs is), I still believe the documentation and the implementation can be improved on this. I think there's even reason to believe that this should be working out of the box. The only reason I see for this not being the default setting is to not add pygments [2] as a dependency. Still, I think it should be much easier for me as a user to spend less time getting it to work. I welcome any feedback on this. Thank you for taking the time to read my proposal. [1] http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-12-2 [2] http://pygments.org/
Re: [O] [Feature Request] Configure timing format
Hello, Koen van der Kruk writes: > I am planning to add a new feature to orgmode, but I don't know if there is > already something like I described below. I am also wondering if someone > could tell me how much time this is going to take. > I have a little experience with orgmode and emacs, but still have to learn > a lot. > > Feature description: > > It currently is not possible to configure the timing format to the > resolution you want. This project is about adding this feature to org-mode. > After implementation, it should be possible to chose any timing resolution > you want, ranging from precision to hours, quarters of an hour, seconds, > milliseconds, etc. The only limitation should be the internal timing > resolution of the operating system on which emacs runs. Moreover, all > functions associated with time (such as automatic calculation of durations > etc. etc. overlays, should also continue to work correctly). Milliseconds > may be overkill, but the point of this project is that it makes org-mode > abstract from a fixed timing resolution, it should be fully > configurable. I don't think timestamps to the millisecond or even the second belong to the scope of this application. If you need this, I suggest to add another syntax for it (e.g., like timers do), but I'm not convinced it should go in core anyway. Real improvements over current timestamps would be to remove the limit of internal timing resolution (e.g., be able to use time stamps before 1970) and, even more importantly, support time zones. Regards, -- Nicolas Goaziou
Re: [O] Multicite syntax
Richard Lawrence writes: > With this change, what's the proper way to get the citation-references > inside a citation? Before this change, one could simply do: > > (org-element-property :references citation) > > to get the references in a citation; what's the equivalent incantation > now? [...] > But, AFAICT, citation objects do not actually have citation-reference > objects within them, at least when returned by org-element-context. `org-element-context' never returns contents of objects or elements. > I'm sure there is something simple I am misunderstanding here about how > nested objects work...can you enlighten me? You could do the following (let ((citation (org-element-lineage (org-element-context) '(citation) t)) references) (save-excursion (goto-char (org-element-property :contents-begin citation)) (let ((end (org-element-property :contents-end citation))) (while (< (point) end) (let ((reference (org-element-lineage (org-element-context) '(citation-reference) t (push reference references) (goto-char (org-element-property :end reference) (nreverse references)) Regards,
Re: [O] [ox, patch] Keywords & what should go in ox?
Nicolas Goaziou writes: > We don't need a convoluted markup for that, let's keep it simple. But then you'd have to repeat data. E.g. #+KEYWORDS: my keywords for meta-data that should also be printed. my keywords for meta-data that should also be printed. This seems error prone and undesirable IMO. —Rasmus -- El Rey ha muerto. ¡Larga vida al Rey!
Re: [O] org-plot jumps over empty columns
Hello,
Anders Wirzenius writes:
> Problem:
> It seems that org-plot/gnuplot assumes there is a non-empty value
> on each row of the table.
>
> Org-plot/gnuplot jumps over empty columns and picks up the value
> from the first non-empty column when executed.
>
> In the example below where column 7 should be plotted, the last two
> values are taken from column 8.
> If I change the column to be plotted from 7 to 8, all values are
> taken from column 9.
>
> Test also plotting column 11 or 12.
>
> -example--example--example--example-
> #+PLOT: set:"xdata time"
> #+PLOT: set:"timefmt '%Y-%m-%d'"
> #+PLOT: set:"format x '%b %Y'"
> #+PLOT: set:"y2tics"
> #+PLOT: set:"xtics rotate"
> #+PLOT: set:"grid"
> #+PLOT: set:"key outside right"
> #+PLOT: title:"Energi" ind:1 deps:(7) type:2d with:lines
> #+PLOT: labels:("datum" "MW" "m**3" "delta_t" "in" "ut" "natt" "dag" "ute"
> "daglig" "el" "vatten" "per vecka" "ute 14")
> | datum | MW | m**3 | delta_t | in | ut | natt | dag | ute | daglig |
> el | vatten | vecka | ute 14 |
> |+-+--+-+++--+-+-+++--+---+|
> | 2008-01-20 | 0.9 | 22 |32.3 | 77 | 44 | 45 | | 1 ||
> -15562 | 247.9692 | 0.10 | -0.93 |
> | 2008-01-21 | 0.9 | 23 |37.4 | 82 | 45 | 47 | | -1 | 0.00 |
> | | 0.12 | -1.79 |
> | 2008-01-22 | 1.1 | 26 |40.8 | 79 | 39 | 45 | | 0 | 0.20 |
> | | 0.12 | -1.71 |
> | 2008-01-23 | 1.2 | 29 |33.6 | 78 | 44 | 47 | | -1 | 0.10 |
> | | 0.12 | -1.64 |
> | 2008-01-24 | 1.3 | 32 |40.7 | 81 | 40 | 44 | | -2 | 0.10 |
> | | 0.12 | -1.57 |
> | 2008-01-25 | 1.4 | 35 |40.2 | 77 | 38 | 46 | | 0 | 0.10 |
> | | 0.12 | -1.36 |
> | 2008-01-26 | 1.5 | 38 |35.7 | 76 | 40 | 36 | | 0 | 0.10 |
> | | 0.12 | -1.21 |
> | 2008-01-27 | 1.6 | 41 |36.0 | 78 | 41 | 41 | | -3 | 0.10 |
> | | 0.12 | -1.07 |
> | 2008-01-28 | 1.8 | 44 |42.6 | 89 | 46 | | 49 | -4 | 0.20 |
> | | 0.10 | -0.93 |
> | 2008-01-29 | 1.9 | 46 |43.9 | 77 | 33 | | 45 | 2 | 0.10 |
> | | 0.12 | -0.86 |
Fixed in 4d7772c6a45398eae1b25a1e4b01283976d2cf06. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] [proposal] enhancement of Org-Mode tables and related features
Hello, Randomcoder writes: > 1) Org-Mode tables currently do not have an easy way to format each > cell individually. For regular text, I can select a region and do M-x > fill-paragraph and that works fine, but for Org-Mode tables, I cannot > do that. Yes, I know about M-x org-table-wrap-region , I have tried to > use it for a few hours, read the manuals, read pages that talked about > it and I was unable to get it working. > > 2) As a user, I'd also really appreciate M-x RET to work better. M-x RET ? > Currently if I go somewhere on a line and run that, the text until > the end of that line is deleted and prepended to the start of the next > line. So, by doing that, I solved the length of the text on the current > line, but now I moved the problem to the next line, where the text is > again longer than it should be. > > 3) I've used C-c ` a few times and tried to make sense of it. As far > as I can tell it only works for one line. > For me personally, in order for C-c ` to be useful, I would expect > it to work on the entire table cell, not just one line in the table > cell. Table cells are at most one line long, there is no such thing as a multi-line table cell in Org. Think of Org tables as a spreadsheet more than a regular table. Regards, -- Nicolas Goaziou
Re: [O] Bug: columns in tables with fixed length affected by folded links
Hello, Randomcoder writes: > I've noticed that if I have a table like this: > > | | >| > |+---| > | Question | Answer >| > |+---| > |Stuff | >| > || [[http://very-long-link/][text that would > fit the column fixed width]] | > || >| > > And I do C-c C-c (or M-x org-table-align) and > org-toggle-link-display to fold the link, it still shows up as "=>" which > means > that Org-Mode has taken into consideration the actual length of the entire > link > when it did the folding. Instead, I propose that it only takes > into consideration the length of the link text. I get an error when trying to align this table (with a lower value than 85). What Org version are you using? Regards, -- Nicolas Goaziou
Re: [O] [proposal] better documentation around syntax highlighting Org-Mode code blocks when exporting to LaTeX
Hello, Randomcoder writes: > While writing technical documents, as a programmer and an Org-Mode user, > for me it's important to have ways to syntax highlight code blocks when > exporting them to LaTeX. > > While I am aware of the customizations that need to be done > to Org-Mode's configuration in order to get that to work, in > particular customizing these variables(see [1] for details): > > * org-latex-listings > * org-latex-custom-lang-environments > * org-latex-minted-options Did you read `org-latex-listings' docstring? If so, what do you think is missing or not clear enough? > and having tried them, I got this working for one document, but it > really felt like a lot of trial-and-error and a lot of room for error > on my side as a user. > > Although this is Org-Mode and it is supposed to be very customizable > (like Emacs is), I still believe the documentation and the implementation > can be improved on this. What do you suggest, concretely? > I think there's even reason to believe that this should be working out > of the box. I think the default value is right. Any other value requires the user additional steps (requiring "listings" package or even adding pygments as a dependency) Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps
Gustav Wikström writes: > Fixed patches are attached, Applied. Thank you. As a final step, would you mind preparing an entry in ORG-NEWS? I think most of it can be extracted from your commit messages. Regards,
Re: [O] [ox, patch] Keywords & what should go in ox?
Hello, Rasmus writes: > First, as discussed a while back we want to move DESCRIPTION and KEYWORDS > out of ox.el as they are specific to certain backends. The first patch > does this. Thanks. You can remove the keywords from "ox-org.el" and "ox-ascii.el", as they do not use them. You need to update (info "(org)Publishing options") accordingly, too. > Second, I want to add support for printing keywords. This patch is still > rough (i.e. no need commenting), but before proceeding I want to discuss > some things. The goal is to allow cool stuff like: > >#+begin_abstract > Read my paper, please... > #+keywords: org, markup >#+end_abstract > > And eventually: > >#+tile: my fancy blog >#+keywords: org, markup > > Where 'org' and 'markup' would magically become links to indexes (like on > them fancy blogs on the interwebs). I'm still not sure how to do the > latter (see TODO comment in patch). I fail to see how it is "cool". KEYWORDS are meant to add contents to meta-data, i.e., an area you cannot reach easily with regular Org syntax. As a consequence, KEYWORDS doesn't mean much for back-ends not supporting such meta-data. If KEYWORDS are meant to be inserted in the buffer, then write them using regular syntax, e.g., #+begin_abstract Read my paper, please... Keywords-in-my-language: [[http://link-to-tag-cloud][org]] #+end_abstract We don't need a convoluted markup for that, let's keep it simple. Regards, -- Nicolas Goaziou
Re: [O] [ox] possible to modify org-export-document-properties OTG
Hello, Rasmus writes: > Is it possible to modify or extend org-export-document-properties on the > go? And would it be OK? `org-export-document-properties' is a defconst, which is computed from `org-element-document-properties', also a defconst. So, no, it isn't meant for that. Document properties are keywords where `org-element-context' is allowed to return an object. It doesn't make sense to add random keywords specific to some export back-ends to the list. > Or should org-element-parse-secondary-string be used with appropriate > limitations? For now, I suggest to use `org-element-parse-secondary-string'. > It would be useful 'cause it's an easy way to have a property parsed. In > ox-koma-letter.el it would make sense to make #+SUBJECT a document > property (ATM org-syntax isn't interpreted). In some backends it would > probably also make sense to make #+KEYWORDS parsed. I'm also working on a > patch to add #+SUBTITLE, which would also benefit from being easily added > as a document-property. You can always use `org-element-parse-secondary-string' on the keyword value and `org-export-data' or `org-export-data-with-backend' on it. At some point, I thought about adding a `parsed' behaviour to `org-export-options-alist' as a shortcut. Sadly, I cannot remember why I didn't implement the idea eventually. It may be related to `org-element-map', which couldn't map over data in such keywords, or the fact that it would be confusing wrt `org-element-context'. E.g., if we consider the two keywords #+TITLE: *boXld* #+PARSED_KÊYWORD_IN_SOME_BACKEND_IGNORED_IN_OTHERS: *boXld* in the former, `org-element-context' at "X" returns a `bold' object, in the latter, a `keyword' element. Note that I'm not arguing it should return a `bold' object in both cases, it really shouldn't, but it can be confusing and potentially trigger false bug reports. Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Jacob Gerlach writes: > Patch attached for fuzzy links. Thank you. > I don't really use code blocks, so I wasn't sure what to do with > org-export-resolve-coderef. Should the final > > (when (re-search... > (cond ... > > become > > (or (re-search... >(cond ... > (error No, the whole body could be wrapped with an `or': (or (org-element-map ...) (user-error "Unable to resolve code reference: %s" ref)) > ID links are tricky. AFAICT, an invalid id link will always resolve to > the file it's contained in. The last check in > org-export-resolve-id-link is looking for the id in `:id-alist'. Is > this the same `:id-alist' built in org-export-get-environment? Yes, it is. > If so, is it desirable for org-id-find-id-file to fall back on the > current buffer (the current behavior)? According to its docstring, `org-id-find-id-file' returns nil when search failed. Isn't it the case? > I don't know the implications of changing org-id-find-id-file. The > fall back behavior was introduced in ac83bc01 when org-id was mostly > rewritten. Removing the fall back behavior doesn't cause any failures > on `make test'. If it's acceptable to remove the fall back, I can > provide a similar patch for org-export-resolve-id-link. `org-export-resolve-id-link' could throw an error, indeed. > Subject: [PATCH] ox.el: Issue error for unresolved fuzzy link > > * lisp/org-capture.el (org-export-resolve-fuzzy-link): throw error ^^^ wrong file You need to capitalize sentence: "Throw an error" > instead of returning nil when link can't be resolved. > > * testing/lisp/test-ox.el (test-org-export/resolve-fuzzy-link): change > last test from should-not to should-error Ditto. > + ;; No destination found: error. > + (unless match-title-p > + (error (format "Unable to resolve link \"%s\"" raw-path) You don't need to check `match-title-p' here. Also, it should be `user-error' instead of `error'. Regards,
Re: [O] [PATCH] document D support
Hello, Thierry Banel writes: > Here is a (small) patch in the documentation to add D in the list of > Babel-supported languages. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [ox, patch] Keywords & what should go in ox?
Rasmus writes: > Nicolas Goaziou writes: > >> We don't need a convoluted markup for that, let's keep it simple. > > But then you'd have to repeat data. E.g. > > #+KEYWORDS: my keywords for meta-data that should also be printed. > my keywords for meta-data that should also be printed. > > This seems error prone and undesirable IMO. Except that this is not a real repetition. As you mentioned, in the latter case, you want to throw in links and probably other markup, which make no sense in plain meta-data. IMO, this is over-engineering. Regards,
Re: [O] PATCH: Processing language support in Babel
Hello, Jarmo Hurri writes: > Please find two files attached to this message. Thank you. > +;; This differs from most standard languages in that > +;; > +;; 1) there is no such thing as a "session" in processing > +;; > +;; 2) results can only be exported as html; in this case, the > +;;processing code is embedded via a file into a javascript block > +;;using the processing.js module; the script then draws the > +;;resulting output when the web page is viewed in a browser > +;; > +;; 3) when not exporting html, evaluation of processing code results > +;;in interactive viewing of the results via Processing 2.0 Emacs > +;;mode; note that the user is responsible for making sure that > +;;processing.js is available on the website It is awkward (and fragile) to guess the current export back-end used. Wouldn't it be simpler to do "2" if :results is html and "3" otherwise? > +;; declaration needed because requiring ob does not define the variable > +(eval-when-compile (defvar org-babel-temporary-directory)) Isn't (defvar org-babel-temporary-directory) sufficient? > +;; default header tags depend on whether exporting html or not; if not > +;; exporting html, then no results are produced; otherwise results are > +;; html It shouldn't. > +;; a running index for producing unique ids for processing sketches > +(defvar org-babel-processing-sketch-number 0) > +(add-hook 'org-export-before-processing-hook > + (lambda (backend) (setq org-babel-processing-sketch-number 0))) It pollutes `org-export-before-processing-hook'. What about using sha1 of the contents of the code block instead? > +(defun org-babel-execute:processing (body params) > + "Execute a block of Processing code. > +This function is called by `org-babel-execute-src-block'." > + (let ((sketch-code > + (org-babel-expand-body:generic > + body > + params > + (org-babel-variable-assignments:processing params > +(if (and (not (null org-babel-exp-reference-buffer)) > + (string= org-export-current-backend "html")) This will not work if current back-end is derived from "html". > + ;; results are html if exporting html > + (let ((sketch-canvas-id > +(concat "org-processing-canvas-" > +(number-to-string org-babel-processing-sketch-number (format "org-processing-canvas-%d" org-babel-processing-sketch-number) > + (setq org-babel-processing-sketch-number > + (1+ org-babel-processing-sketch-number)) (incf org-babel-processing-sketch-number) > +(defun org-babel-processing-define-type (data) > + "Determine type of DATA. > + > +DATA is a list. Return type as a symbol. > + > +The type is `String' if any element in DATA is > +a string. Otherwise, it is either `float', if some elements are > +floats, or `int'." > + (let* ((type 'int) > + find-type ; for byte-compiler > + (find-type > + (function Not needed. > +(lambda (row) > + (catch 'exit > +(mapc (lambda (el) > +(cond ((listp el) (funcall find-type el)) > + ((stringp el) (throw 'exit (setq type 'String))) > + ((floatp el) (setq type 'float > + row)) (lambda (row) (dolist (el row type) (cond ...))) > +(funcall find-type data) type)) not needed Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Hello, Thanks for the feedback. On Sun, Mar 15, 2015 at 4:44 AM, Nicolas Goaziou wrote: >> I don't really use code blocks, so I wasn't sure what to do with >> org-export-resolve-coderef. [...] > No, the whole body could be wrapped with an `or': > > (or (org-element-map ...) > (user-error "Unable to resolve code reference: %s" ref)) I tried this, or more specifically: (or ((org-element-map ... info 'first-match)) (user-error ... and got a failure on test-org-export/resolve-coderef. It's not obvious to me from reading the tests if there is a test that needs to be changed, or if it's a legitimate failure and a different approach is needed (or if I made a mistake). I asked in [1] for some guidance on tests, and I'm still lost. >> If so, is it desirable for org-id-find-id-file to fall back on the >> current buffer (the current behavior)? > > According to its docstring, `org-id-find-id-file' returns nil when > search failed. Isn't it the case? Are you looking at `org-id-find-id-in-file' rather than `org-id-find-id-file'? The docstring for `org-id-find-file' only says: "Query the id database for the file in which this ID is located." [...] > `org-export-resolve-id-link' could throw an error, indeed. I'm not clear on the way forward for id links. I propose removing the fall back behavior in `org-id-find-id-file'. If that's acceptable, I can provide a patch for `org-export-resolve-id-link'. >> Subject: [PATCH] ox.el: Issue error for unresolved fuzzy link [...] Commit message fixed. I also updated the docstring for org-export-resolve-fuzzy link. >> + ;; No destination found: error. >> + (unless match-title-p >> + (error (format "Unable to resolve link \"%s\"" raw-path) > > You don't need to check `match-title-p' here. Also, it should be > `user-error' instead of `error'. OK. Updated fuzzy link patch attached. Regards, Jake [1] http://thread.gmane.org/gmane.emacs.orgmode/96017 From a9221500b721a501f7b7f05519dfc0d6f30f23d0 Mon Sep 17 00:00:00 2001 From: Jacob Gerlach Date: Wed, 11 Mar 2015 22:39:11 -0400 Subject: [PATCH] ox.el: Issue error for unresolved fuzzy link * lisp/ox.el (org-export-resolve-fuzzy-link): Throw an error instead of returning nil when link can't be resolved. * testing/lisp/test-ox.el (test-org-export/resolve-fuzzy-link): Change last test from should-not to should-error In addition to throwing an error, don't store the failed match in the link cache. TINYCHANGE --- lisp/ox.el | 8 testing/lisp/test-ox.el | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/lisp/ox.el b/lisp/ox.el index 0c7728f..9461117 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -4021,7 +4021,7 @@ Return value can be an object, an element, or nil: will be given to the one with the closest common ancestor, if any, or the first one in the parse tree otherwise. -- Otherwise, return nil. +- Otherwise, report an error. Assume LINK type is \"fuzzy\". White spaces are not significant." @@ -4068,7 +4068,7 @@ significant." ;; Last case: link either points to a headline or to nothingness. ;; Try to find the source, with priority given to headlines with ;; the closest common ancestor. If such candidate is found, - ;; return it, otherwise return nil. + ;; return it, otherwise signal an error. (t (let ((find-headline (function @@ -4094,8 +4094,8 @@ significant." (org-element-lineage parent-hl nil t (let ((foundp (funcall find-headline path parent))) (when foundp (throw 'exit foundp - ;; No destination found: return nil. - (and (not match-title-p) (puthash path nil link-cache + ;; No destination found: error. + (user-error (format "Unable to resolve link \"%s\"" raw-path (defun org-export-resolve-id-link (link info) "Return headline referenced as LINK destination. diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el index 1b70a78..7cf1e1d 100644 --- a/testing/lisp/test-ox.el +++ b/testing/lisp/test-ox.el @@ -2478,8 +2478,8 @@ Another text. (ref:text) (org-element-type (org-export-resolve-fuzzy-link (org-element-map tree 'link 'identity info t) info) - ;; Return nil if no match. - (should-not + ;; Error if no match. + (should-error (org-test-with-parsed-data "[[target]]" (org-export-resolve-fuzzy-link (org-element-map tree 'link 'identity info t) info))) -- 1.9.1
Re: [O] Citation syntax: a revised proposal
Hi Andreas, Andreas Leha writes: > I have been following this thread from (quite) some distance as I am > very interested in more general citation support from orgmode. Please > allow some basic questions: > > 1. For the LaTeX user > This change means that the LaTeX user can use org syntax for citations > rather than bare LaTeX (or links of some sort)? > > And this org syntax could then (I guess is the future) be extended with > additional link-like functionality (maybe similar to org-ref)? Yes, exactly. > 2. The non-LaTeX exports > These are all treated the same and will contain just text, that is > produced to mimic LaTeX's output to some extent? Well, that depends on what you mean by `just' text. Citations can still contain or be wrapped in markup that is specific to the output format, like span tags or anchor tags in HTML. > I think I read some question about e.g. having zotero handling the > citations in the odt export. Are there plans for such thing? Maybe. As far as I know, no one has done any work on Zotero integration yet. But Vaidheeswaran did some work to make JabRef (a different reference database) handle citations in ODT export. > 3. The database > As I understand the database currently is either bibtex or org? Yes. > But that list could in principle be extended to zotero ... ? Yes, in principle. Any database that can export to bibtex format is supported to some degree, if we support that format. Whether we want to integrate with any particular reference database more tightly than that hasn't really been discussed, as far as I'm aware. I don't have a good sense of what other software Org users rely on for this purpose. > And any other database X (zotero ...) would need translations X -> > bibtex to make the LaTeX export work with it as well? Not necessarily. Obviously, if you want to have bibtex/biblatex do the processing of the citations and bibliography in the document, that is required. But there is another approach, which is the one that Pandoc takes: directly rendering citations and bibliography into the output .tex file. If you're not relying on bibtex/biblatex to do the rendering, you don't need to have the database in its format. The org-citeproc tool I've been working on supports reading databases in any of these formats (via pandoc-citeproc): FormatFile extension -- MODS .mods BibLaTeX .bib BibTeX.bibtex RIS .ris EndNote .enl EndNote XML .xml ISI .wos MEDLINE .medline Copac .copac JSON citeproc .json org-citeproc (via pandoc-citeproc) should already be able to read databases in these other formats. It would be trivial to add a LaTeX writer to org-citeproc that would allow rendering citations and bibliographies directly, as Pandoc does (since org-citeproc is just a small wrapper around pandoc and pandoc-citeproc). > 4. Example > Could you post one of your examples? I'd love to see the prototype in > action to have a proper picture of this. A couple of other people (Vaidheeswaran, Aaron Ecay) have posted examples in other messages. Here's an example of a simple Org document being processed by org-citeproc: #+BEGIN_SRC org #+OPTIONS: toc:nil todo:t |:t #+TITLE: Org-Citeproc Test #+AUTHOR: Richard Lawrence #+LANGUAGE: en #+BIBDB: bibtex ~/Documents/philosophy/dissertation/build/dissertation.bib #+CSL_FILE: /tmp/chicago-author-date.csl Citations and Bibliography are supported using org-citeproc. Here's a couple of them. [(cite): @Brandom1994] [(cite): @Russell1919] [(cite): @Vaanaanen2011] And one textual cite to throw in the mix: [cite: See @Caponigro2003]. #+BIBLIOGRAPHY: here #+END_SRC In plain text, the body renders like: #+BEGIN_QUOTE Citations and Bibliography are supported using org-citeproc. Here's a couple of them. (Brandom 1994) (Russell 2001) (Väänäänen 2011) And one textual cite to throw in the mix: Caponigro (See 2003). Brandom, Robert. 1994. _Making It Explicit_. Harvard University Press. Caponigro, Ivano. 2003. “Free Not to Ask: On the Semantics of Free Relatives and Wh-Words Cross-Linguistically.” PhD thesis, University of California, Los Angeles. Russell, Bertrand. 2001. “Descriptions.” In _The Philosophy of Language_, edited by A. P. Martinich, Fourth, 221–27. Oxford University Press. Väänäänen, Jouko. 2011. _Models and Games_. Vol. 132. Cambrdige Studies in Advanced Mathematics. Cambridge University Press. #+END_QUOTE And in HTML, the relevant parts of the body look like this (hopefully, you can see this unescaped HTML in your mail/news reader): #+BEGIN_QUOTE Citations and Bibliography are supported using org-citeproc. Here's a couple of them. (Brandom 1994) (Russell 2001) (Väänäänen 2011) And one textual cite to throw in the mix: Cap
Re: [O] Multicite syntax
Hi Nicolas, Nicolas Goaziou writes: > `org-element-context' never returns contents of objects or elements. > >> I'm sure there is something simple I am misunderstanding here about how >> nested objects work...can you enlighten me? > > You could do the following > > (let ((citation (org-element-lineage (org-element-context) '(citation) t)) > references) > (save-excursion > (goto-char (org-element-property :contents-begin citation)) > (let ((end (org-element-property :contents-end citation))) > (while (< (point) end) > (let ((reference (org-element-lineage > (org-element-context) '(citation-reference) t > (push reference references) > (goto-char (org-element-property :end reference) > (nreverse references)) Thanks! Just to clarify: I see that this is necessary when getting a citation object via org-element-context, but is it also necessary in an export context, where the whole buffer or region has already been parsed? I ask because in that kind of context, I think it is generally going to be more useful to deal with citation objects as a whole. I am not sure we will want to treat citation-references as individual objects which are themselves exported; instead, I think we will want to handle exporting the citation-references in a citation all at once. Best, Richard
[O] [patch, koma-letter] Change of subject behavior
Hi, I want to change the subject inference in ox-koma-letter to only happen on top-level headlines. Thus, in the following example the opening would be "opening" and not "h1" as it is currently. * opening ** h1 Typically, "h1" is just there to help me organize the letter. Any objections? —Rasmus -- Together we will make the possible totay impossible! >From 2ce18b7f061109f0006fb1b823029d35fee4f9a9 Mon Sep 17 00:00:00 2001 From: Rasmus Date: Tue, 17 Mar 2015 18:32:26 +0100 Subject: [PATCH] ox-koma-letter: Stricter subject inference * ox-koma-letter.el (org-koma-letter-headline): Subject can only be inferred from top-level heading. --- contrib/lisp/ox-koma-letter.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index 1b5dd17..1e905a9 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -561,7 +561,8 @@ appropriate place." (push (cons tag contents) org-koma-letter-special-contents))) ;; Opening is not defined yet: use headline's title. (when (and org-koma-letter-headline-is-opening-maybe - (not (org-string-nw-p (plist-get info :opening + (not (org-string-nw-p (plist-get info :opening))) + (eq 1 (org-export-get-relative-level headline info))) (plist-put info :opening (org-export-data (org-element-property :title headline) info))) ;; In any case, insert contents in letter's body. -- 2.3.3
[O] Org to mindmap and back
Hi, While searching for mind mapping tools that already had some integration with orgmode, I found this video: https://www.youtube.com/watch?v=93cqGFu3B-g, which shows a simple (but seemingly powerful) mindmapping tool that integrates well with org. Unfortunately the link to the code / app is nowhere to be found in the video description and the video is pretty old. It'd be unfortunate to not share such an interesting project. I'm very interested in using/testing/extending it. I'm wondering if the author still lurks around this mailing list? *ping* Either way, it's a great idea and someone else (even myself) could get some inspiration out off it and create something similar (and share!) - I've been wanting a way to visualize my org files in the form of a mindmap and keep both representations synced so I could just switch when I wanted, and this seems to be the gist of it. Cheers, -- Marcelo
Re: [O] Export to google docs spreadsheet
Thanks Eric! That will do it. On Tue, Mar 17, 2015 at 2:53 AM, Eric S Fraga wrote: > On Monday, 16 Mar 2015 at 22:10, Marcelo de Moraes Serpa wrote: > > Hi all, > > > > Is there a way to export an orgmode spreadsheet to a format that can be > > imported by google docs? > > M-x org-table-export RET > > will export to TSV or CSV which you can read into any spreadsheet > program although I have no idea what google docs may expect or allow. > > -- > : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org > release_8.3beta-895-g375c83 >
Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps
Hi again!
Comments below.
> From: Nicolas Goaziou [mailto:m...@nicolasgoaziou.fr]
> > +(taggroups (if downcased (mapcar (lambda (tg) (mapcar #'downcase
> > tg))
> > + taggroups) taggroups))
>
> Nitpick: indentation
Can't see what's wrong.. Autoindent by emacs did this. Anyways.. I made the
if-construct clearer by adding linebreaks.
> > + (delq nil (mapcar (lambda (x)
> > + (if (stringp x)
> > + (and (equal "{" (substring x 0 1))
> > +(equal "}" (substring x -1))
> > +x)
> > + x)) tags-in-group))
>
> Same here. TAGS-IN-GROUP should be at the same level as (lambda (x) ...)
Ok, fixed.
> > + regexp-in-group
> > + (mapcar (lambda (x)
> > + (substring x 1 -1)) regexp-in-group-escaped)
>
> Ditto.
Fixed.
> > + tags-in-group
> > + (delq nil (mapcar (lambda (x)
> > + (if (stringp x)
> > + (and (not (equal "{" (substring x 0
> > 1)))
> > +(not (equal "}" (substring x
> > -1)))
> > +x)
> > + x))
> > tags-in-group)))
>
> Ditto.
Fixed.
> > + ; If single-as-list, do no more in the while-loop...
> > + (if (not single-as-list)
> > + (progn
> > + (if regexp-in-group
> > + (setq regexp-in-group (concat "\\|" (mapconcat
> > 'identity regexp-in-group "\\|"
> > + (setq tags-in-group (concat dir "{\\<" (regexp-opt
> > tags-in-group) regexp-in-group "\\>}"))
>
> You need to keep lines within 80 columns.
Trying to avoid it.
> > + (when (member tg g)
> > + (mapc (lambda (x)
> > + (setq current (delete x current)))
> > + g)))
>
> While you're at it:
>
> (when (member tg g) (dolist (x g) (setq current (delete x current
Ok!
> > +(defun org-agenda-filter-by-tag (arg &optional char exclude)
> >"Keep only those lines in the agenda buffer that have a specific tag.
> > The tag is selected with its fast selection letter, as configured.
> > -With prefix argument STRIP, remove all lines that do have the tag.
> > -A lisp caller can specify CHAR. NARROW means that the new tag should be
> > -used to narrow the search - the interactive user can also press `-' or `+'
> > -to switch to narrowing."
> > +With a single `C-u' prefix ARG, exclude the agenda search. With a
> > +double `C-u' prefix ARG, filter the literal tag. I.e. don't filter on
> ^^^
> missing space
Fixed.
> Also, instead of hard-coding `C-u', you could use \\[universal-argument]
> within the doc string. See, for example, `org-tree-to-indirect-buffer'.
Fixed.
> > +(exclude (if exclude exclude (equal arg '(4
>
> (exclude (or exclude (equal arg '(4
Fixed.
> > + (while (not (memq char (append '(?\t ?\r ?/ ?. ?\ ?q)
> > +(string-to-list tag-chars
>
> For clarity, use ?\s instead of ?\
Fixed.
> Also, I suggest to move the consing before the while loop.
Good point, changed.
> > + ((eq char ?. )
>
> Spurious space.
Fixed.
> > + ((or (eq char ?\ )
>
> See above.
Fixed.
>
> > + (save-match-data
> > + (let (tags-expanded)
> > + (dolist (x (cdr tags-in-group))
> > + (if (and (member x taggroups-keys)
> > +(not (member x work-already-expanded)))
> > + (setq tags-expanded (delete-dups
> > +(append (org-tags-expand x t
> > downcased work-already-expanded)
> > +tags-expanded)))
> > + (setq tags-expanded (append (list x) tags-expanded)))
> > + (setq work-already-expanded (delete-dups (append
> > tags-expanded work-already-expanded
> > + (setq tags-in-group (delete-dups (cons (car tags-in-group)
> > +
> > tags-expanded)
>
> Lines too wide.
Ok, fixed kind of. I don't want to compromise on the relatively long variable
names.
>
> > +Tags can be defined in hierarchies. A tag can be defined as a @emph{group
> ^^^
> missing space
Fixed.
> > @lisp
> > -(setq org-tag-alist '((:startgroup . nil)
> > +(setq org-tag-alist '((:startgrouptag . nil)
> >("@@read" . nil)
> >(:grouptags . nil)
> >
[O] bug#20090: 24.4: linking to a position within an info node
> When the org mode manual discusses creating links, it gives an example > of linking to an info node (the self-referencing example is > `info:org#External' links). The manual continues, at node > `info:org#Search options', to describe how specific positions within > file links can be directly specified. This does work for links to > regular files, but does not work for positions within an info node (eg. > line 85 of node x). Is there an official format for the line numbers in Info cross-references? (info "(texinfo) Printing Indices & Menus") documents the format of line numbers only in the index, not in the cross-references: * In Info output, `@printindex' produces a special menu containing the line number of the entry, relative to the start of the node. Info readers can use this to go to the exact line of an entry, not just the containing node. (Older Info readers will just go to the node.) Here's an example: * First index entry: Top. (line 7) The actual number of spaces is variable, to right-justify the line number; it's been reduced here to make the line fit in the printed manual. The Info reader already supports this format in the index.
[O] Bug: columns in tables with fixed length affected by folded links
Hi, I've noticed that if I have a table like this: | | | |+---| | Question | Answer | |+---| |Stuff | | || [[http://very-long-link/][text that would fit the column fixed width]] | || | And I do C-c C-c (or M-x org-table-align) and org-toggle-link-display to fold the link, it still shows up as "=>" which means that Org-Mode has taken into consideration the actual length of the entire link when it did the folding. Instead, I propose that it only takes into consideration the length of the link text. I'm not sure what part of the code is responsible for this. I am reporting this as a bug here on the mailing list.
[O] bug#18870: \emsp and alignment in org clock report
I confirm this behaviour. With a plain text terminal, a clock report shows like: |---+--++--+--| | willow-it.org | *File time* | *5:25* | | | | | Willow IT| 5:25 | | | | | \emsp Administration || 3:44 | | | | \emsp\emsp Induction || | 3:44 | | | \emsp Training & development || 1:41 | | | | \emsp\emsp Odoo research || | 1:41 | |---+--++--+--| The "\emsp" should be space characters (of some kind; either U+0020 SPC or U+2003 EM SPACE) with correct alignment for the character width. Displaying literal "\emsp" is a regression and should not happen. If having a U+2003 EM SPACE character is desirable, then instead of LaTeX-specific markup (which is useless in the text buffer), that character should appear directly in the data so it is useful for display. Thanks for working on Org Mode. -- Ben Finney
[O] [bug] ox-md and ox-man use same shortcut
Both ox-man and ox-md use "m" as their menu-entry shortcut. Witch make them merge as one in the org-export-dispatch if they are both loaded at the same time. Maybe ox-man should use "M" instead of "m".
[O] bug#20090: 24.4: linking to a position within an info node
On 03/12/2015 03:50 PM, Juri Linkov wrote: >> When the org mode manual discusses creating links, it gives an example >> of linking to an info node (the self-referencing example is >> `info:org#External' links). The manual continues, at node >> `info:org#Search options', to describe how specific positions within >> file links can be directly specified. This does work for links to >> regular files, but does not work for positions within an info node (eg. >> line 85 of node x). > > Is there an official format for the line numbers in Info cross-references? I don't know - my assumption was that within emacs, it would be basically just another type of emacs buffer, and be a legitimate subject for all elisp commands. Your question got me thinking, that emacs may have subtle rendering quirks, so just now, I opened fresh instances of info buffers in both very wide and very narrow windows, and they both `fill' to the same line length, ie the wide window has a lot of right-side white-space, and the narrow window has lines wrapped. Since I submitted the bug report, I've continued trying to get the feature working, and have been experimenting with the org-mode hooks `org-create-file-search-functions' and `org-execute-file-search-functions' to no success. The only, supposedly working examples I've come across for these functions are [1] and [2]. If you know of other resources, that could be helpful. One other possible related bug I've found is that when trying to use org-store-link for a particular line number within an org-file, the link is created to the most recent header. One can successfully, manually, hack the created link, replacing the reference to the header with a line number, in order to be able to navigate directly to the desired line (all this, for a link target in an org mode file - this was done as a test, once I came across the original bug) [3]. [1] https://stackoverflow.com/questions/10681766/emacs-org-mode-textual-reference-to-a-fileline [2] http://www.emacswiki.org/emacs/.emacs-DominiqueQuatravaux.el [3] info:org#Search options > > (info "(texinfo) Printing Indices & Menus") documents the format of > line numbers only in the index, not in the cross-references: > >* In Info output, `@printindex' produces a special menu containing > the line number of the entry, relative to the start of the node. > Info readers can use this to go to the exact line of an entry, not > just the containing node. (Older Info readers will just go to the > node.) Here's an example: > > * First index entry: Top. (line 7) > > The actual number of spaces is variable, to right-justify the line > number; it's been reduced here to make the line fit in the printed > manual. > > The Info reader already supports this format in the index. > -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 signature.asc Description: OpenPGP digital signature
[O] Bug: refile error with org-inlinetask [8.2.10 (release_8.2.10 @ /usr/share/emacs/24.4/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Hello, I cannot refile tasks with the package org-inlinetask. In the example below, I get the error message "The kill is not a (set of) tree(s) - please use to yank anyway". Here is below a minimal example. #+BEGIN_EXAMPLE * a * b ** b1 ** b2 *** TODO this is a test task *** END #+END_EXAMPLE Configuration: #+BEGIN_EXAMPLE ;;; Minimal setup to load latest `org-mode' ;; activate debugging (setq debug-on-error t debug-on-signal nil debug-on-quit nil) ;; add latest org-mode to load path (add-to-list 'load-path (expand-file-name "/usr/share/org-mode/lisp")) (add-to-list 'load-path (expand-file-name "/usr/share/emacs/site-lisp/emacs-goodies-el")) (require 'org-inlinetask) #+END_EXAMPLE And the contents of the messages buffer: #+BEGIN_EXAMPLE For information about GNU Emacs and the GNU system, type C-h C-a. (New file) ESC is undefined Saving file /home/damien/org/refile-inline.org... Wrote /home/damien/org/refile-inline.org Getting targets...done Copied: Subtree(s) with 41 characters user-error: The kill is not a (set of) tree(s) - please use to yank anyway user-error: Minibuffer window is not active Getting targets...done Making completion list... Copied: Subtree(s) with 41 characters user-error: The kill is not a (set of) tree(s) - please use to yank anyway #+END_EXAMPLE best regards, Damien Emacs : GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-07 on trouble, modified by Debian Package: Org-mode version 8.2.10 (release_8.2.10 @ /usr/share/emacs/24.4/lisp/org/) current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-shell-link-function 'yes-or-no-p org-font-lock-hook '(org-inlinetask-fontify) org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) )
[O] org-entitites aren't translated when in LaTeX fragments
org-entitites aren't translated when used in a LaTeX fragment.
For example when exporting $a = by(t) \rarr y(t+1) = by^{2}(t)$ to
HTML I get \(a = by(t) \rarr y(t+1) = by^{2}(t)\) whereas I should get
\(a = by(t) \rightarrow y(t+1) = by^{2}(t)\).
\rarr isn't translated to \rightarrow witch make MathJax unhappy:
Undefined control sequence \rarr
Looks like this bug as been reported in 2010
(http://thread.gmane.org/gmane.emacs.orgmode/22628/) but hasn't been
fixed yet.
[O] [PATCH] Org mode manual proofreading
Hi!
I just read the Org mode manual (it was a good read, thanks!), and
noted formatting- and spelling errors I found along the way. The
attached patch corrects those.
This is my first time contributing to Org mode. I have signed the FSF
papers for Emacs earlier.
-- Simen
>From 497f8a29cfa21328094d4ff5418ac9722ee4d8d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Simen=20Heggest=C3=B8yl?=
Date: Fri, 13 Mar 2015 20:18:41 +0100
Subject: [PATCH] org.texi: Fix numerous typos
* org.texi: Fix numerous formatting- and typing errors.
---
doc/org.texi | 56 +---
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index b701fd7..4020636 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -2437,7 +2437,7 @@ of a @emph{column formula} that will be applied to all non-header fields in a
column without having to copy the formula to each relevant field. There is
also a formula debugger, and a formula editor with features for highlighting
fields in the table corresponding to the references at the point in the
-formula, moving these references by arrow keys
+formula, moving these references by arrow keys.
@menu
* References:: How to refer to another field or range
@@ -2575,9 +2575,9 @@ Insert the doubled value of each column of row 1 of the table named
@noindent For the second/third example, the table named @code{FOO} must have
at least as many rows/columns as the current table. Note that this is
-inefficient@footnote{The computation time scales as O(N^2) because the table
-named @code{FOO} is parsed for each field to be read.} for large number of
-rows/columns.
+inefficient@footnote{The computation time scales as O(N@math{^2}) because the
+table named @code{FOO} is parsed for each field to be read.} for large number
+of rows/columns.
@subsubheading Named references
@cindex named references
@@ -2723,7 +2723,7 @@ $0;%.1f @r{Reformat current cell to 1 decimal}
($3-32)*5/9 @r{Degrees F -> C conversion}
$c/$1/$cm@r{Hz -> cm conversion, using @file{constants.el}}
tan($1);Dp3s1@r{Compute in degrees, precision 3, display SCI 1}
-sin($1);Dp3%.1e @r{Same, but use printf specifier for display}
+sin($1);Dp3%.1e @r{Same, but use @samp{printf} specifier for display}
taylor($3,x=7,2) @r{Taylor series of $3, at x=7, second degree}
@end example
@@ -2770,7 +2770,7 @@ not enough.
If a formula starts with a single-quote followed by an opening parenthesis,
then it is evaluated as a Lisp form. The evaluation should return either a
string or a number. Just as with @file{calc} formulas, you can specify modes
-and a printf format after a semicolon.
+and a @samp{printf} format after a semicolon.
With Emacs Lisp forms, you need to be conscious about the way field
references are interpolated into the form. By default, a reference will be
@@ -3566,7 +3566,7 @@ exact headline will be matched, ignoring spaces and cookies. If the value is
@code{query-to-create}, then an exact headline will be searched; if it is not
found, then the user will be queried to create it.}
file:projects.org::*task title @r{heading search in Org
-file}@footnote{ Headline searches always match the exact headline, ignoring
+file}@footnote{Headline searches always match the exact headline, ignoring
spaces and cookies. If the headline is not found and the value of the option
@code{org-link-search-must-match-exact-headline} is @code{query-to-create},
then the user will be queried to create it.}
@@ -3728,7 +3728,7 @@ valid link prefixes like @samp{http:} or @samp{ftp:}, including the prefixes
defined through link abbreviations (@pxref{Link abbreviations}). If you
press @key{RET} after inserting only the @var{prefix}, Org will offer
specific completion support for some link types@footnote{This works by
-calling a special function @code{org-PREFIX-complete-link}.} For
+calling a special function @code{org-PREFIX-complete-link}.}. For
example, if you type @kbd{file @key{RET}}, file name completion (alternative
access: @kbd{C-u C-c C-l}, see below) will be offered, and after @kbd{bbdb
@key{RET}} you can complete contact names.
@@ -3887,7 +3887,7 @@ called with the tag as the only argument to create the link.
With the above setting, you could link to a specific bug with
@code{[[bugzilla:129]]}, search the web for @samp{OrgMode} with
@code{[[google:OrgMode]]}, show the map location of the Free Software
-Foundation @code{[[gmap:51 Franklin Street, Boston]]} or of Carsten office
+Foundation @code{[[gmap:51 Franklin Street, Boston]]} or of Carsten's office
@code{[[omap:Science Park 904, Amsterdam, The Netherlands]]} and find out
what the Org author is doing besides Emacs hacking with
@code{[[ads:Dominik,C]]}.
@@ -5231,7 +5231,7 @@ or with a tree they need to be inserted into a special drawer
right below a headline, and its planning line (@pxref{Deadlines and
scheduling}) when
Re: [O] Multicite syntax
Hello, Richard Lawrence writes: > Nicolas Goaziou writes: >> You could do the following >> >> (let ((citation (org-element-lineage (org-element-context) '(citation) t)) >> references) >> (save-excursion >> (goto-char (org-element-property :contents-begin citation)) >> (let ((end (org-element-property :contents-end citation))) >> (while (< (point) end) >> (let ((reference (org-element-lineage >> (org-element-context) '(citation-reference) t >> (push reference references) >> (goto-char (org-element-property :end reference) >> (nreverse references)) > > Thanks! For correctness, (push ...) and (goto-char ...) obviously need to be located within the (let ...). > Just to clarify: I see that this is necessary when getting a citation > object via org-element-context, but is it also necessary in an export > context, where the whole buffer or region has already been parsed? No, with a full parse tree, `org-element-contents' on a citation object returns the list of all citation-reference objects within. > I ask because in that kind of context, I think it is generally going to > be more useful to deal with citation objects as a whole. I am not sure > we will want to treat citation-references as individual objects which > are themselves exported; instead, I think we will want to handle > exporting the citation-references in a citation all at once. I don't know. In any case, they need to be treated as regular object (e.g., they are expected to have a filter associated to them). If some back-end doesn't need to export directly citation references, it just needs to skip the relative translator. Regards, -- Nicolas Goaziou
Re: [O] Citation syntax: a revised proposal
Hi Richard, Thank you very much for your detailed answer. Richard Lawrence writes: > Hi Andreas, > > Andreas Leha writes: > >> I have been following this thread from (quite) some distance as I am >> very interested in more general citation support from orgmode. Please >> allow some basic questions: >> >> 1. For the LaTeX user >> This change means that the LaTeX user can use org syntax for citations >> rather than bare LaTeX (or links of some sort)? >> >> And this org syntax could then (I guess is the future) be extended with >> additional link-like functionality (maybe similar to org-ref)? > > Yes, exactly. > >> 2. The non-LaTeX exports >> These are all treated the same and will contain just text, that is >> produced to mimic LaTeX's output to some extent? > > Well, that depends on what you mean by `just' text. Citations can still > contain or be wrapped in markup that is specific to the output format, > like span tags or anchor tags in HTML. > I meant especially link-like functionality in the exported document. Just as references in a LaTeX generated PDF can link to the bibliography (and back). >> I think I read some question about e.g. having zotero handling the >> citations in the odt export. Are there plans for such thing? > > Maybe. As far as I know, no one has done any work on Zotero integration > yet. But Vaidheeswaran did some work to make JabRef (a different > reference database) handle citations in ODT export. > >> 3. The database >> As I understand the database currently is either bibtex or org? > > Yes. > >> But that list could in principle be extended to zotero ... ? > > Yes, in principle. Any database that can export to bibtex format is > supported to some degree, if we support that format. Whether we want to > integrate with any particular reference database more tightly than that > hasn't really been discussed, as far as I'm aware. I don't have a good > sense of what other software Org users rely on for this purpose. > >> And any other database X (zotero ...) would need translations X -> >> bibtex to make the LaTeX export work with it as well? > > Not necessarily. Obviously, if you want to have bibtex/biblatex do the > processing of the citations and bibliography in the document, that is > required. But there is another approach, which is the one that Pandoc > takes: directly rendering citations and bibliography into the output > .tex file. If you're not relying on bibtex/biblatex to do the > rendering, you don't need to have the database in its format. > > The org-citeproc tool I've been working on supports reading databases in > any of these formats (via pandoc-citeproc): > > FormatFile extension > -- > MODS .mods > BibLaTeX .bib > BibTeX.bibtex > RIS .ris > EndNote .enl > EndNote XML .xml > ISI .wos > MEDLINE .medline > Copac .copac > JSON citeproc .json > > org-citeproc (via pandoc-citeproc) should already be able to read > databases in these other formats. It would be trivial to add a LaTeX > writer to org-citeproc that would allow rendering citations and > bibliographies directly, as Pandoc does (since org-citeproc is just a > small wrapper around pandoc and pandoc-citeproc). > I see. Very interesting. >> 4. Example >> Could you post one of your examples? I'd love to see the prototype in >> action to have a proper picture of this. > > A couple of other people (Vaidheeswaran, Aaron Ecay) have posted > examples in other messages. Here's an example of a simple Org document > being processed by org-citeproc: > [ deleted the examples ] Thank you very much. These look really nice! > > Note that citations containing multiple references are not supported at > the moment, but that is coming soon. > > Best, > Richard This citation support will make my lock-in into orgmode perfect, I guess. Thanks again, Andreas
Re: [O] [patch, koma-letter] Change of subject behavior
Hello,
Rasmus writes:
> I want to change the subject inference in ox-koma-letter to only happen on
> top-level headlines.
>
> Thus, in the following example the opening would be "opening" and not "h1"
> as it is currently.
>
> * opening
> ** h1
>
> Typically, "h1" is just there to help me organize the letter.
>
> Any objections?
This is a bug indeed.
However, I don't think :opening setting belongs to
`org-koma-letter-headline', as it means it is potentially set each time
a headline is being processed.
The (when ...) could be moved within `org-koma-letter-template', where
"\opening{...}" is filled and the first headline without a special tag
in the parse tree could be used (assuming there's no special
keyword...). That headline can be found using `org-element-map'.
Another (smallish) advantage is that the following case would be
allowed:
* Dear myself,
* Part 1
WDYT?
Regards,
--
Nicolas Goaziou
[O] bug#18870: \emsp and alignment in org clock report
Hello, Ben Finney writes: > I confirm this behaviour. > > With a plain text terminal, a clock report shows like: > > |---+--++--+--| > | willow-it.org | *File time* | *5:25* | | > | > | | Willow IT| 5:25 | | > | > | | \emsp Administration || 3:44 | > | > | | \emsp\emsp Induction || | > 3:44 | > | | \emsp Training & development || 1:41 | > | > | | \emsp\emsp Odoo research || | > 1:41 | > |---+--++--+--| > > The "\emsp" should be space characters (of some kind; either U+0020 SPC > or U+2003 EM SPACE) with correct alignment for the character width. > Displaying literal "\emsp" is a regression and should not happen. This is not a regression. This change favors a correct export over a correct display. Having some space character is not desirable as it would just move the problem the other way around (i.e., indentation would not appear during export) In a nutshell, the current situation is not perfect, but we have yet to find a proper character to preserve both indentation during export and readability. > If having a U+2003 EM SPACE character is desirable, then instead of > LaTeX-specific markup (which is useless in the text buffer), that > character should appear directly in the data so it is useful for > display. Note that this is not LaTeX-specific markup. This is called an entity, and is correctly exported in various back-ends. Regards, -- Nicolas Goaziou
Re: [O] Citation syntax: a revised proposal
Hi Andreas, Andreas Leha writes: >>> 2. The non-LaTeX exports >>> These are all treated the same and will contain just text, that is >>> produced to mimic LaTeX's output to some extent? >> >> Well, that depends on what you mean by `just' text. Citations can still >> contain or be wrapped in markup that is specific to the output format, >> like span tags or anchor tags in HTML. >> > > I meant especially link-like functionality in the exported document. > Just as references in a LaTeX generated PDF can link to the bibliography > (and back). I don't see why this couldn't be done, at least in the direction from link to bibliography entry. (I don't think the other direction will work, as the relationship is generally one-many.) I'll think about the best way to add this; the problem is adding unique identifiers to bibliography entries when generating them, which hopefully shouldn't be too difficult. Best, Richard
[O] bug#18870: \emsp and alignment in org clock report
On 17-Mar-2015, Nicolas Goaziou wrote: > Hello, > > Ben Finney writes: > > > The "\emsp" should be space characters (of some kind; either > > U+0020 SPC or U+2003 EM SPACE) with correct alignment for the > > character width. Displaying literal "\emsp" is a regression and > > should not happen. > > This is not a regression. This change favors a correct export over > a correct display. The behaviour described – displaying “\emsp” instead of space characters – is a regression. That's what is being reported in this bug. > Having some space character is not desirable as it would just move > the problem the other way around (i.e., indentation would not appear > during export) So the U+2003 EM SPACE character should be translated *during export*, and not be literally in the displayed text. > In a nutshell, the current situation is not perfect, but we have yet > to find a proper character to preserve both indentation during > export and readability. IS the above suggestion an acceptable solution? > Note that this is not LaTeX-specific markup. This is called an entity, > and is correctly exported in various back-ends. But not for display, which is the bug to be fixed here. Thanks for working on Org mode. -- \ “The future always arrives too fast, and in the wrong order.” | `\—Alvin Toffler | _o__) | Ben Finney signature.asc Description: Digital signature
Re: [O] Org to mindmap and back
Marcelo de Moraes Serpa writes: > Hi, > > While searching for mind mapping tools that already had some > integration with orgmode, I found this video: > https://www.youtube.com/watch?v=93cqGFu3B-g, which shows a simple (but > seemingly powerful) mindmapping tool that integrates well with org. > > Unfortunately the link to the code / app is nowhere to be found in the > video description and the video is pretty old. It'd be unfortunate to > not share such an interesting project. I'm very interested in > using/testing/extending it. I'm wondering if the author still lurks > around this mailing list? *ping* > > Either way, it's a great idea and someone else (even myself) could get > some inspiration out off it and create something similar (and share!) - > I've been wanting a way to visualize my org files in the form of a > mindmap and keep both representations synced so I could just switch > when I wanted, and this seems to be the gist of it. > > Cheers, > > -- Marcelo There is a connection to Freemind in the source tree. Not near my computer right now. The name is something like ox-freemind.el... Dave
[O] bug#18870: \emsp and alignment in org clock report
Ben Finney writes: > The behaviour described – displaying “\emsp” instead of space > characters – is a regression. That's what is being reported in this > bug. There wasn't space characters in the first place, but "\___" constructs. See commit bacfe5b4f7244eaf151f4e26a1d94dd8f66c1d19. Also, the bug is about table alignment when `org-pretty-entities' is used. >> Having some space character is not desirable as it would just move >> the problem the other way around (i.e., indentation would not appear >> during export) > > So the U+2003 EM SPACE character should be translated *during export*, > and not be literally in the displayed text. No, because it means this character should be treated specially by Org (e.g., LaTeX just ignores it so it needs to be turned into a space there). This is not a good idea, especially considering it is an invisible character. > IS the above suggestion an acceptable solution? No, it isn't. An acceptable solution would be a character or a string that looks decent both in the buffer and in an exported document, without further processing. >> Note that this is not LaTeX-specific markup. This is called an entity, >> and is correctly exported in various back-ends. > > But not for display, which is the bug to be fixed here. Actually, it works more or less correctly for display on GUI with a non-nil `org-pretty-entities', or calling `org-toggle-pretty-entities'. Regards,
[O] More export filter examples out there?
I'm trying to accomplish a custom export task which I'd hoped to be pretty simple: something like: In each status section, only export the first child headline. After several dumb ideas, I decided that doing it with a filter was probably the Right Place. I built a filter intended to be used on :filter-parse-tree and attempted to express: If you're parent is a headline and your parent's title is 'Status' and you're not the first of your siblings then don't be included. I've added my malfunctioning filter below,to clearly display my "thinking". I don't seem to be able to get the title as a string. org-export-data seems to expect a different 'info' than the 'info' present at filter time. I get complaints about org-export-data: Wrong type argument: hash-table-p, nil if I uncomment the attempt to string compare the title. I'm finding my experience with XSLT to be a handicap; I bring expectations to the table that are misguided. Is there a pretty-printer or other dump for the export parse tree? The dump I sometimes get in *Messages* is not all that readable. Should I be thinking of this as a parse-table operation, or should I be reasoning about it from :filter-headline? More generally, anyone got some art for some similar reconstruction they've done, which they might like to share? - Allen S. Rout (defun ox-asr-only-first-status ( tree backend info ) " Arrange that, under headlines marked 'Status', only the first of them is included. " ( org-element-map tree (remq 'item org-element-all-elements) ( lambda (e) ( let* ( ( parent ( org-element-property :parent e) ) ( first-sib( car (org-element-contents parent ))) ( parent-type ( org-element-type parent )) ( parent-title ( org-element-property :title e)) ; ( pt-string( org-export-data parent-title info )) ) (if (and ( eq parent-type 'headline ) ( not (eq e first-sib )) ;( string= (org-export-data parent-title) "Status") ) ( org-element-set-contents e "-->" parent-title "<--- " (org-element-contents e)) ) ) ) ) tree )
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Jacob Gerlach writes: > I tried this, or more specifically: > (or ((org-element-map > ... > info 'first-match)) > (user-error ... > and got a failure on test-org-export/resolve-coderef. It's not > obvious to me from reading the tests if there is a test that needs to > be changed, or if it's a legitimate failure and a different approach > is needed (or if I made a mistake). I asked in [1] for some guidance > on tests, and I'm still lost. There is a spurious (...) in the code above. I implemented it in a886b234763f288670103d2c98169164dedec06c. >> According to its docstring, `org-id-find-id-file' returns nil when >> search failed. Isn't it the case? > Are you looking at `org-id-find-id-in-file' rather than > `org-id-find-id-file'? The docstring for `org-id-find-file' only says: > "Query the id database for the file in which this ID is located." You're right. >> `org-export-resolve-id-link' could throw an error, indeed. > I'm not clear on the way forward for id links. I propose removing the > fall back behavior in `org-id-find-id-file'. If that's acceptable, I > can provide a patch for `org-export-resolve-id-link'. Actually, we don't even need to do that. I changed "ox.el" so it uses `org-id-find' instead of `org-id-find-id-file'. The former has a better fall-back value. See e0b19dedb99d3c01199a159a2da8f9aa4adb2f6f > Updated fuzzy link patch attached. Applied (with minor tweaks). Thank you. Regards,
Re: [O] [patch, koma-letter] Change of subject behavior
Nicolas Goaziou writes:
> However, I don't think :opening setting belongs to
> `org-koma-letter-headline', as it means it is potentially set each time
> a headline is being processed.
The property is at most set once cf. the second clause.
> The (when ...) could be moved within `org-koma-letter-template', where
> "\opening{...}" is filled and the first headline without a special tag
> in the parse tree could be used (assuming there's no special
> keyword...). That headline can be found using `org-element-map'.
Yes. Less ugly.
> Another (smallish) advantage is that the following case would be
> allowed:
>
> * Dear myself,
> * Part 1
Is the advantage that it won't fold?
> WDYT?
The current stuff is ugly. I didn't know much lisp when I worked on
ox-koma-letter.
I updated the patch. Perhaps the loop determination shod be moved to a
separate function to keep the template clean. I thinking this cause we
(or at least I) sometimes point to ox-koma-letter as an example of a
derived backend. WDTY on that?
In the attached at least this work as expected.
*** ps :ps:
*** dear you,
* part 1
—Rasmus
--
Send from my Emacs
>From dacee19cce07a75735298dcb3f3730d6220248c5 Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Tue, 17 Mar 2015 18:32:26 +0100
Subject: [PATCH] ox-koma-letter: Stricter subject inference
* ox-koma-letter.el (org-koma-letter-headline): Remove opening guessing.
(org-koma-letter-template): Directly infer subject from first
non-special headline.
---
contrib/lisp/ox-koma-letter.el | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 1b5dd17..59616c7 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -412,6 +412,7 @@ was not present."
(:with-place nil "place" org-koma-letter-use-place)
(:with-subject nil "subject" org-koma-letter-subject-format)
(:with-title-as-subject nil "title-subject" org-koma-letter-prefer-subject)
+(:with-headline-opening nil nil org-koma-letter-headline-is-opening-maybe)
;; Special properties non-nil when a setting happened in buffer.
;; They are used to prioritize in-buffer settings over "lco"
;; files. See `org-koma-letter-template'.
@@ -559,11 +560,6 @@ appropriate place."
tag (mapcar #'symbol-name (plist-get info :special-tags)))
;; Store association for later use and bail out.
(push (cons tag contents) org-koma-letter-special-contents)))
-;; Opening is not defined yet: use headline's title.
-(when (and org-koma-letter-headline-is-opening-maybe
- (not (org-string-nw-p (plist-get info :opening
- (plist-put info :opening
- (org-export-data (org-element-property :title headline) info)))
;; In any case, insert contents in letter's body.
contents))
@@ -641,7 +637,21 @@ holding export options."
(format "\\begin{letter}{%%\n%s}\n\n"
(org-koma-letter--determine-to-and-from info 'to))
;; Opening.
- (format "\\opening{%s}\n\n" (plist-get info :opening))
+ (format "\\opening{%s}\n\n"
+ (org-export-data
+ (or (org-string-nw-p (plist-get info :opening))
+ (if (plist-get info :with-headline-opening)
+ (let ((special-tags (plist-get info :special-tags)))
+ (org-element-map (org-element-parse-buffer) 'headline
+ (lambda (head)
+ (unless
+(org-some 'identity
+ (mapcar (lambda (tag) (memq (intern tag) special-tags))
+ (org-element-property :tags head)))
+ (org-element-property :title head)))
+ info t)))
+ "")
+ info))
;; Letter body.
contents
;; Closing.
--
2.3.3
Re: [O] More export filter examples out there?
Hello, "Allen S. Rout" writes: > I'm trying to accomplish a custom export task which I'd hoped to be > pretty simple: something like: > > > In each status section, only export the first child headline. > > > After several dumb ideas, I decided that doing it with a filter was > probably the Right Place. I built a filter intended to be used on > > :filter-parse-tree > > and attempted to express: > > If you're parent is a headline > and your parent's title is 'Status' > and you're not the first of your siblings > > then don't be included. I've added my malfunctioning filter below,to > clearly display my "thinking". Untested: (defun ox-asr-only-first-status (tree backend info) (org-element-map tree 'headline (lambda (h) (let ((parent (org-export-get-parent-headline h))) (when (and parent (string= (org-element-property :raw-value parent) "Status") (not (org-export-first-sibling-p h info))) (org-element-extract-element h) tree) > I don't seem to be able to get the title as a string. Use `:raw-value' property. > org-export-data seems to expect a different 'info' than the 'info' > present at filter time. I get complaints about > > org-export-data: Wrong type argument: hash-table-p, nil > > if I uncomment the attempt to string compare the title. Indeed. One cannot use `org-export-data' during parse tree filtering. Export output really depends on the tree and the options, which are being re-arranged. Regards, -- Nicolas Goaziou
Re: [O] [patch, koma-letter] Change of subject behavior
Rasmus writes: > Nicolas Goaziou writes: >> However, I don't think :opening setting belongs to >> `org-koma-letter-headline', as it means it is potentially set each time >> a headline is being processed. > > The property is at most set once cf. the second clause. By "potentially set", I meant the (trivial) check would be done nonetheless, which is a waste. >> Another (smallish) advantage is that the following case would be >> allowed: >> >> * Dear myself, >> * Part 1 > > Is the advantage that it won't fold? No, since * Dear myself, * Part 1 won't fold either, but in "** Dear myself," stands out and doesn't look like a standard container. > I updated the patch. Perhaps the loop determination shod be moved to a > separate function to keep the template clean. Yes, it needs to be factored out (maybe `org-koma-letter--special-headline-p') since it is also used in `org-koma-letter-headline'. What about (defun org-koma-letter--special-headline-p (h info) (let ((special-tags (plist-get info :special-tags))) (org-some (lambda (tag) (assoc-string tag special-tags)) (org-export-get-tags h info > I thinking this cause we (or at least I) sometimes point to > ox-koma-letter as an example of a derived backend. WDTY on that? What do you mean? > +(:with-headline-opening nil nil > org-koma-letter-headline-is-opening-maybe) I don't think this line is required. Regards,
Re: [O] [patch, koma-letter] Change of subject behavior
Nicolas Goaziou writes: >> I updated the patch. Perhaps the loop determination shod be moved to a >> separate function to keep the template clean. > > Yes, it needs to be factored out (maybe > `org-koma-letter--special-headline-p') since it is also used in > `org-koma-letter-headline'. What about > > (defun org-koma-letter--special-headline-p (h info) > (let ((special-tags (plist-get info :special-tags))) > (org-some (lambda (tag) (assoc-string tag special-tags)) > (org-export-get-tags h info That's nice. I had forgotten about org-export-get-tags. >> + (:with-headline-opening nil nil >> org-koma-letter-headline-is-opening-maybe) > > I don't think this line is required. It feels more consistent to provide the check through the definition, but I'm not willing to pick a fight over this so it's back to just checking the variable. I have only tested the patch briefly as I need to actually produce a letter. But for the letter I'm writing export works fine. —Rasmus -- To err is human. To screw up 10⁶ times per second, you need a computer >From ec5c3ed3f6e1e3cfec5f6264f7b30dbef745aeb4 Mon Sep 17 00:00:00 2001 From: rasmus Date: Wed, 19 Nov 2014 15:39:19 +0100 Subject: [PATCH] org.el: Add keyword-support to M-RET * org.el (org-insert-keyword): New function. (org-meta-return): May call `org-insert-keyword'. --- lisp/org.el | 30 -- 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index dbd2cb7..8862f16 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -21286,6 +21286,23 @@ number of stars to add." (forward-line))) (unless toggled (message "Cannot toggle heading from here" +(defun org-insert-keyword (&optional arg) + "Insert a new keyword at point. + +ARG may be used to specify a keyword. Otherwise the keyword is determined from the context. + +Mainly used for `org-meta-return'." + ;; Roughly based on + ;; TODO: Respect `org-M-RET-may-split-line'. + ;; TODO: Behave differently based on whether at beginning or + ;; end of line. E.g. M-RET at pos 0 adds line ABOVE. + + (interactive "P") + (let* ((elm (org-element-at-point)) + (key (or arg (and (eq 'keyword (org-element-type elm)) + (org-element-property :key elm) +(and key (insert (format "\n#+%s: " key) + (defun org-meta-return (&optional arg) "Insert a new heading or wrap a region in a table. Calls `org-insert-heading' or `org-table-wrap-region', depending @@ -21298,12 +21315,13 @@ on context. See the individual commands for more information." (when (eq type 'table-row) (setq element (org-element-property :parent element)) (setq type 'table)) -(if (and (eq type 'table) - (eq (org-element-property :type element) 'org) - (>= (point) (org-element-property :contents-begin element)) - (< (point) (org-element-property :contents-end element))) -(call-interactively 'org-table-wrap-region) - (call-interactively 'org-insert-heading) +(cond ((and (eq type 'table) + (eq (org-element-property :type element) 'org) + (>= (point) (org-element-property :contents-begin element)) + (< (point) (org-element-property :contents-end element))) + (call-interactively 'org-table-wrap-region)) + ((eq type 'keyword) (call-interactively 'org-insert-keyword)) + (t (call-interactively 'org-insert-heading)) ;;; Menu entries -- 2.1.3
Re: [O] Citation syntax: a revised proposal
On Tue, Mar 17, 2015 at 12:26 PM, Richard Lawrence <
richard.lawre...@berkeley.edu> wrote:
> Hi Andreas,
>
> Andreas Leha writes:
>
> > I have been following this thread from (quite) some distance as I am
> > very interested in more general citation support from orgmode. Please
> > allow some basic questions:
> >
> > 1. For the LaTeX user
> > This change means that the LaTeX user can use org syntax for citations
> > rather than bare LaTeX (or links of some sort)?
> >
> > And this org syntax could then (I guess is the future) be extended with
> > additional link-like functionality (maybe similar to org-ref)?
>
> Yes, exactly.
>
> > 2. The non-LaTeX exports
> > These are all treated the same and will contain just text, that is
> > produced to mimic LaTeX's output to some extent?
>
> Well, that depends on what you mean by `just' text. Citations can still
> contain or be wrapped in markup that is specific to the output format,
> like span tags or anchor tags in HTML.
>
> > I think I read some question about e.g. having zotero handling the
> > citations in the odt export. Are there plans for such thing?
>
> Maybe. As far as I know, no one has done any work on Zotero integration
> yet. But Vaidheeswaran did some work to make JabRef (a different
> reference database) handle citations in ODT export.
>
> > 3. The database
> > As I understand the database currently is either bibtex or org?
>
> Yes.
>
> > But that list could in principle be extended to zotero ... ?
>
> Yes, in principle. Any database that can export to bibtex format is
> supported to some degree, if we support that format. Whether we want to
> integrate with any particular reference database more tightly than that
> hasn't really been discussed, as far as I'm aware. I don't have a good
> sense of what other software Org users rely on for this purpose.
>
Just a note about Zotero: I think for most of us, the reason to export
into ODT and/or DOC is to circulate a paper either for review or
collaboration. Either case will likely involve some revision to citations,
which would ideally be handled through Zotero. for this to work properly,
we would want to export a full Zotero citation. To do that, we would
likely need to speak directly to Zotero iteself. Here is a snippet of xml
from a Zotero-generated citation in an odt document:
--
Here is a cite.
1
http://resolver.scholarsportal.info/resolve/14626268/v21i0001/63_beauc.xml.}","plainCitation":"Lea
Schick, “Bodies, Embodiment and Ubiquitous Computing” 21, no. 1 (March 1,
2010): 63–69,
http://resolver.scholarsportal.info/resolve/14626268/v21i0001/63_beauc.xml.";
},"citationItems":[{"id":5262,"uris":["
http://zotero.org/users/20/items/AJGK5FDE"],"uri":[";
http://zotero.org/users/20/items/AJGK5FDE"],"itemData":{"id":5262,"type":"article-journal","title":"Bodies,
embodiment and ubiquitous
computing","page":"63-69","volume":"21","issue":"1","URL":"
http://resolver.scholarsportal.info/resolve/14626268/v21i0001/63_beauc.xml"
;,"ISSN":"14626268","author":[{"family":"Schick","given":"Lea"}],"issued":{"date-parts":[["2010",3,1]]}}}],"schema":"
https://github.com/citation-style-language/schema/raw/master/csl-citation.json"}
RNDXQmSceXdkV"/>
Lea Schick, “Bodies, Embodiment
and Ubiquitous Computing” 21, no. 1 (March 1, 2010): 63–69,
http://resolver.scholarsportal.info/resolve/14626268/v21i0001/63_beauc.xml.
http://resolver.scholarsportal.info/resolve/14626268/v21i0001/63_beauc.xml.}","plainCitation":"Lea
Schick, “Bodies, Embodiment and Ubiquitous Computing” 21, no. 1 (March 1,
2010): 63–69,
http://resolver.scholarsportal.info/resolve/14626268/v21i0001/63_beauc.xml.";
},"citationItems":[{"id":5262,"uris":["
http://zotero.org/users/20/items/AJGK5FDE"],"uri":[";
http://zotero.org/users/20/items/AJGK5FDE"],"itemData":{"id":5262,"type":"article-journal","title":"Bodies,
embodiment and ubiquitous
computing","page":"63-69","volume":"21","issue":"1","URL":"
http://resolver.scholarsportal.info/resolve/14626268/v21i0001/63_beauc.xml"
;,"ISSN":"14626268","author":[{"family":"Schick","given":"Lea"}],"issued":{"date-parts":[["2010",3,1]]}}}],"schema":"
https://github.com/citation-style-language/schema/raw/master/csl-citation.json"}
RNDXQmSceXdkV"/>
---
Among other pieces of data, it contains a reference to a zotero URL which i
don't think org-citeproc will know about. Can you describe what would be
necessary to get text like this into an ODT, using ythe code you've been
working on? THis conversation has gone a bit beyond my competence/comfort
level, but I would be interested i nhelping a bit as soon as our semester
is over here (just a couple of weeks left).
Thanks,
Matt
> > And any other database X (zotero ...) would need translations X ->
> > bibtex to make the LaTeX export work with it as well?
>
> Not necessarily. Obviously, if you want to have b
[O] spreadsheet-like "fill down" in org tables?
I'm starting to use org tables quite a bit. One thing I would like to do is to quickly fill in one or more cells using the value from a cell directly above. In spreadsheets one usually does this by grabbing a cell "handle" and draggind downwards. Is there anything analogous in org? Thanks, Matt
Re: [O] spreadsheet-like "fill down" in org tables?
On 17 March 2015, Matt Price wrote: I'm starting to use org tables quite a bit. One thing I would like to do is to quickly fill in one or more cells using the value from a cell directly above. In spreadsheets one usually does this by grabbing a cell "handle" and draggind downwards. Is there anything analogous in org? Shift-RET will copy in what's in the cell above. Bill -- William Denton ↔ Toronto, Canada ↔ https://www.miskatonic.org/
Re: [O] Org to mindmap and back
Hi Dave, Yes, I'm aware of the freemind exporter. I'm not very fond of freemind though, I find it clunky to use. I really liked the minimalist style of the mind-mapping application shown in the video (also the animation effects are cool, too). Would be great if the author could chime in and perhaps share the code. Heck, I'd be willing to buy it if the integration with org was good enough (both-ways auto synchronization). On Tue, Mar 17, 2015 at 3:59 PM, J. David Boyd wrote: > Marcelo de Moraes Serpa writes: > > > Hi, > > > > While searching for mind mapping tools that already had some > > integration with orgmode, I found this video: > > https://www.youtube.com/watch?v=93cqGFu3B-g, which shows a simple (but > > seemingly powerful) mindmapping tool that integrates well with org. > > > > Unfortunately the link to the code / app is nowhere to be found in the > > video description and the video is pretty old. It'd be unfortunate to > > not share such an interesting project. I'm very interested in > > using/testing/extending it. I'm wondering if the author still lurks > > around this mailing list? *ping* > > > > Either way, it's a great idea and someone else (even myself) could get > > some inspiration out off it and create something similar (and share!) - > > I've been wanting a way to visualize my org files in the form of a > > mindmap and keep both representations synced so I could just switch > > when I wanted, and this seems to be the gist of it. > > > > Cheers, > > > > -- Marcelo > > There is a connection to Freemind in the source tree. Not near my computer > right now. The name is something like ox-freemind.el... > > Dave > > >
Re: [O] org-plot jumps over empty columns
Nicolas Goaziou writes: > > Fixed in 4d7772c6a45398eae1b25a1e4b01283976d2cf06. Thank you. > > > Regards, Working nicely. Thank you. -- Anders
