Re: [O] Citation syntax: a revised proposal
jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes: > I see, so in the examples provided Doe99 is only the key, org would > not have to know that the author name is Doe and its year is 1999, > or any other information about the citation. Yes and no. In the first place org should only get a special syntax for citations. That means there will be special data structures for citations and backends get a uniform interface for these parts of the source text. In the simple case that's all, i.e. the backends get more information to generate the correct commands (in the case of LaTeX) or to call some tool that will generate the text/object to be inserted in the resulting document. On the other hand org should be able to show additional information for citations, like linking to its data (in some bib file, in zotero or wherever). But that's a second step. > But now it is not clear to me what the actual org reference points > to. If it is the actual reference, I mean the article's PDF or URL, > what would you do when you need to cite a physical book? The org element, say "[cite: see @doe99]", will point to some data source, to be defined in the same org document (e.g. with "#+BIBIOGRAPHY:..."). This data source for citations may be a bib file, a zotero database, maybe even Endnote or something else. As said above, org will not handle every aspect of citation. It should only know a little more about these things in order to enable some extra features (e.g. special UI for citations or exporting citations to different backends instead of the need to fallback to LaTeX commands). -- Until the next mail..., Stefan.
Re: [O] [patch] better(?) indention for cdlatex-environment
Hi,
> Another idea: [...]
Good trick. I used it in attached, which I think works well.
—Rasmus
--
With monopolies the cake is a lie!
>From 4ab1df88e5bf87d01594e280af7887cc6cd0d3ca Mon Sep 17 00:00:00 2001
From: rasmus
Date: Tue, 10 Feb 2015 12:02:59 +0100
Subject: [PATCH] org.el: Change indention for cdlatex environments
* org.el (org-cdlatex-environment-indent): Use different indent
algorithm based on content above the new latex-environment.
---
lisp/org.el | 52 +++-
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 4f047b2..6de53f1 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18645,12 +18645,54 @@ Revert to the normal definition outside of these fragments."
(call-interactively (key-binding (vector last-input-event))
(defun org-cdlatex-environment-indent (&optional environment item)
- "Execute `cdlatex-environment' and indent the inserted environment."
+ "Execute `cdlatex-environment' and indent the inserted environment.
+
+ENVIRONMENT and ITEM are passed to `cdlatex-environment'.
+
+The inserted environment is indented to current indentation
+unless point is at the beginning of the line, in which the
+environment remains unintended."
(interactive)
- (cdlatex-environment environment item)
- (let ((element (org-element-at-point)))
-(org-indent-region (org-element-property :begin element)
- (org-element-property :end element
+ ;; cdlatex-environment always return nil. Therefore, capture output
+ ;; first and determine if an environment was selected.
+ (let* ((beg (point-marker))
+ (end (copy-marker (point) t))
+ (env (org-trim
+ (or (progn (ignore-errors (cdlatex-environment environment item))
+ (delete-and-extract-region beg end))
+ ""
+(when (org-string-nw-p env)
+ ;; Get indentation of next line unless at column 0.
+ (let ((ind (if (bolp) 0
+ (save-excursion
+ (org-return-indent)
+ (prog1 (org-get-indentation)
+ (when (and (skip-chars-forward " \t") (eolp))
+ (delete-region beg (point)))
+ (bol (and (skip-chars-backward " \t") (bolp
+ ;; Insert a newline before environment unless at column zero
+ ;; to "escape" the current line. Insert a newline if
+ ;; something is one the same line as \end{ENVIRONMENT}.
+ (insert (concat (unless bol "\n")
+ env
+ (and (skip-chars-forward " \t") (not (eolp)) "\n")))
+ (unless (zerop ind)
+ (let* ((element (org-element-at-point))
+ (elm-beg (org-element-property :begin element))
+ (elm-end (copy-marker
+ (save-excursion
+ (goto-char (org-element-property :end element))
+ (skip-chars-backward " \t\n\r")
+ (point)
+ (save-excursion
+ (goto-char elm-beg)
+ (beginning-of-line)
+ (while (<= (point) elm-end)
+ (org-indent-to-column ind)
+ (forward-line)))
+ (set-marker elm-end nil)
+(set-marker beg nil)
+(set-marker end nil)))
LaTeX fragments
--
2.3.0
Re: [O] [RFC] Simplify `org-show-context' configuration
Kyle Meyer writes: Thanks for the feedback. > Minor: It took me some extra effort to parse this sentence because I'm > not used to seeing 'respectively' used in this way. I think something > like below is more common. > > As special cases, a nil or t value means show all contexts in > `minimal' or `full' view, respectively. Updated. Thank you. >> (defun org-reveal (&optional siblings) >>"Show current entry, hierarchy above it, and the following headline. >> -This can be used to show a consistent set of context around locations >> -exposed with `org-show-hierarchy-above' or `org-show-following-heading' >> -not t for the search context. >> + >> +This can be used to show a consistent set of context around >> +locations exposed with `org-show-context'. >> >> With optional argument SIBLINGS, on each level of the hierarchy all >> siblings are shown. This repairs the tree structure to what it would > > Does a single C-u serve a purpose anymore? Without it, it is `lineage' view. With it, it is `canonical' (but I forgot to update it). I'm not sure we need the distinction however. Also, I'm not sure how useful double C-u is. Regards,
Re: [O] [RFC] Simplify `org-show-context' configuration
Nicolas Goaziou wrote: > As explained in its commit message, the following patch is an attempt at > simplifying `org-show-context' configuration by offering a set of > 5 predefined views to choose from instead of setting 4 different > variables (`org-show-following-heading', `org-show-siblings', > `org-show-entry-below' and `org-show-hierarchy-above'). These views are > > minimalshow current headline, and entry below if needed > local show current headline, entry below and next headline > lineageshow direct ancestors and all siblings of current headline; > show entry only if required > canonical show direct ancestors and all of their siblings; show entry > only if required > full show direct ancestors, all their siblings and entry [...] > > I think this is enough, but I can add more views if needed. > > WDYT? I prefer this to the old setup. From a configuration standpoint, it's much nicer to have all the relevant information in one variable. [...] > +As a special case, a nil (respectively t) value means > +`minimal' (respectively `full') detail level for all contexts. Minor: It took me some extra effort to parse this sentence because I'm not used to seeing 'respectively' used in this way. I think something like below is more common. As special cases, a nil or t value means show all contexts in `minimal' or `full' view, respectively. [...] > (defun org-reveal (&optional siblings) >"Show current entry, hierarchy above it, and the following headline. > -This can be used to show a consistent set of context around locations > -exposed with `org-show-hierarchy-above' or `org-show-following-heading' > -not t for the search context. > + > +This can be used to show a consistent set of context around > +locations exposed with `org-show-context'. > > With optional argument SIBLINGS, on each level of the hierarchy all > siblings are shown. This repairs the tree structure to what it would Does a single C-u serve a purpose anymore? -- Kyle
Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags search agendas
Hello, Sebastien Vauban writes: > I guess it's directly linked to a problem I reported last > September. This is indeed annoying... > > See issue #29 on http://orgmode.org/worg/org-issues.html (and see the > pointed thread). This isssue seems fixed. Can you confirm it? Regards, -- Nicolas Goaziou
Re: [O] [bug?, ob] finding tables with captions
Hello,
Rasmus writes:
> A caption seems to prevent Org from finding a table when using inline
> calls. Consider this example:
>
> #+NAME: tbl0
> #+CAPTION: caption
> | a | b |
> |---+---|
> | 1 | 2 |
>
> src_emacs-lisp[:var val=tbl0[2,1]]{val} =nil=
>
> #+CAPTION: caption
> #+NAME: tbl1
> | a | b |
> |---+---|
> | 1 | 2 |
>
> src_emacs-lisp[:var val=tbl1[2,1]]{val} =2=
>
> Is that a feature or a bug? Or me misusing ob?
Babel sometimes assumes NAME is just before the element considered, e.g.
"ob-core.el", l. 1940.
The library would benefit from using the parser consistently, but there
is much work left to do in that area.
Regards,
--
Nicolas Goaziou
Re: [O] Sverweis like function for orgtbl
Thank you John and Michael for your suggestions, I will see if my knowledge is wide enough to understand this, unfortunately I'm a emacs newbie :-) Anyway I will answer after testing your suggestions! Regards Thorsten
[O] [bug?, ob] finding tables with captions
Hi,
A caption seems to prevent Org from finding a table when using inline
calls. Consider this example:
#+NAME: tbl0
#+CAPTION: caption
| a | b |
|---+---|
| 1 | 2 |
src_emacs-lisp[:var val=tbl0[2,1]]{val} =nil=
#+CAPTION: caption
#+NAME: tbl1
| a | b |
|---+---|
| 1 | 2 |
src_emacs-lisp[:var val=tbl1[2,1]]{val} =2=
Is that a feature or a bug? Or me misusing ob?
—Rasmus
--
There are known knowns; there are things we know that we know
[O] [RFC] Simplify `org-show-context' configuration
Hello, As explained in its commit message, the following patch is an attempt at simplifying `org-show-context' configuration by offering a set of 5 predefined views to choose from instead of setting 4 different variables (`org-show-following-heading', `org-show-siblings', `org-show-entry-below' and `org-show-hierarchy-above'). These views are minimalshow current headline, and entry below if needed local show current headline, entry below and next headline lineageshow direct ancestors and all siblings of current headline; show entry only if required canonical show direct ancestors and all of their siblings; show entry only if required full show direct ancestors, all their siblings and entry To sum it up, if original buffer is * H1 * H2 ** Sub 1 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 ** Sub 3 and match is on "Text", minimal is * H1 * H2 * Sub sub 2 Text `local' is * H1 * H2 *** Sub sub 2 Text *** Sub sub 3 `lineage' is * H1 * H2 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 `canonical' and `full' are * H1 * H2 ** Sub 1 ** Sub 2 *** Sub sub 1 *** Sub sub 2 Text *** Sub sub 3 *** Sub sub 4 ** Sub 3 Note that neither `canonical' nor `full' are possible to obtain with the 4 original variables. "if required"/"if needed" means the entry will only be shown if point is within the entry (i.e., not on the headline). Thus, for example, `canonical' and `full' only differ when match is on a headline, since only latter will show the entry. I think this is enough, but I can add more views if needed. WDYT? Regards, -- Nicolas Goaziou0x80A93738 >From c04351a77a7d3af99d292f71e33d43f7e72410d2 Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Mon, 16 Feb 2015 21:43:35 +0100 Subject: [PATCH] Simplify `org-show-context' configuration * lisp/org.el (org-show-context-detail): New variable. (org-context-choice, org-show-following-heading, org-show-siblings, org-show-entry-below, org-show-hierarchy-above): Remove variables. (org-show-set-visibility): New function. (org-get-location, org-show-context, org-reveal): Use new function. (org-link-search): Update docstring. * lisp/org-agenda.el (org-agenda-cycle-show): Use new function. Configuration of `org-show-context' is done with a single variable offering five different views, instead of four variables for a total of 16 configurations. --- lisp/org-agenda.el | 15 ++--- lisp/org.el| 190 ++--- 2 files changed, 86 insertions(+), 119 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 9f2d9d1..f7406d7 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8696,11 +8696,12 @@ if it was hidden in the outline." (defvar org-agenda-cycle-counter nil) (defun org-agenda-cycle-show (&optional n) "Show the current entry in another window, with default settings. -Default settings are taken from `org-show-hierarchy-above' and siblings. -When use repeatedly in immediate succession, the remote entry will cycle -through visibility -children -> subtree -> folded +Default settings are taken from `org-show-context-detail'. When +use repeatedly in immediate succession, the remote entry will +cycle through visibility + + children -> subtree -> folded When called with a numeric prefix arg, that arg will be passed through to `org-agenda-show-1'. For the interpretation of that argument, see the @@ -9521,11 +9522,7 @@ a timestamp can be added there." (unless (bolp) (insert "\n")) (unless (org-looking-at-p "^[ \t]*$") (save-excursion (insert "\n"))) (when org-adapt-indentation (org-indent-to-column col))) - (let ((org-show-following-heading t) - (org-show-siblings t) - (org-show-hierarchy-above t) - (org-show-entry-below t)) -(org-show-context))) + (org-show-set-visibility 'canonical)) (defun org-agenda-diary-entry () "Make a diary entry, like the `i' command from the calendar. diff --git a/lisp/org.el b/lisp/org.el index 4f047b2..bbabb9a 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -1165,87 +1165,67 @@ effective." :tag "Org Reveal Location" :group 'org-structure) -(defconst org-context-choice - '(choice -(const :tag "Always" t) -(const :tag "Never" nil) -(repeat :greedy t :tag "Individual contexts" - (cons - (choice :tag "Context" - (const agenda) - (const org-goto) - (const occur-tree) - (const tags-tree) - (const link-search) - (const mark-goto) - (const bookmark-jump) - (const isearch) - (const default)) - (boolean - "Contexts for the reveal options.") - -(defcustom org-show-hierarchy-above '((default . t)) - "Non-nil means show full hierarchy when revealing a location. -Org-mode ofte
Re: [O] on the fragility of export to ODT
Hello, Eric S Fraga writes: > At this point, I get very long data structures dumped to > *Messages*... difficult to figure out what is wrong. It's often my > mistake but tracking it down is difficult. You're using an internal link to target a paragraph (possibly a image or some such). This is apparently not supported yet by ox-odt (see `org-odt-link--infer-description'). Could you try to find out the culprit and explain what you expected so I can fix it? > However, more importantly, the failure is complete and nothing is > exported which does not help me at all. It would be great if offending > paragraphs (elements, objects, whatever) would be skipped over and the > rest of the document generated. Is this possible? At the moment, I think it is better to fix the errors than to ignore them. There are quite a few "FIXME" in ox-odt. Regards, -- Nicolas Goaziou
Re: [O] Sverweis like function for orgtbl
Hi Thorsten On Mon, Feb 16, 2015 at 4:01 PM, Thorsten Grothe wrote: > I got this table: > > | Menge (x) | P(x) | E(x) | K(x) | Gewinn | > |---+--+++-| > | 0 | 20 | 0.00 | 140.00 | -140.00 | > |10 | 18 | 180.00 | 180.00 | 0.00| > |20 | 16 | 320.00 | 220.00 | 100.00 | > |30 | 14 | 420.00 | 260.00 | 160.00 | > > and would like to find the highest value in the column "Gewinn" = 160 go > two cells left to E(x), read out the value (420) and put this in a remote > orgtbl. This is something similar to Sverweis in Excel. For a solution with a table formula see (info "(org) Lookup functions") or http://orgmode.org/manual/Lookup-functions.html It contains also a link to a tutorial. Michael
Re: [O] Citation syntax: a revised proposal
t...@tsdye.com (Thomas S. Dye) writes: >> Biblatex is the gold standard. Maybe not in input-aesthetics..., but in >> terms of amenability, usability and output it surely is. (No, I have >> nothing to back this up). > > Compare the bibtex style, chicago.bst, with biblatex-chicago and note > how much more closely the biblatex version approximates the Chicago > Manual of Style. Before biblatex-chicago, I used to generate my own bst files with custom-bib. It was awful 'cause I would often answer questions wrong and would have to start over... > Also, biber is required for some biblatex features that bibtex doesn't > support. I haven't followed this development and am not sure what they > are, though. My understanding is that a major limitation of bibtex was that it didn't handle sorting of anything more complex than [a-zA-Z]. Bibtex8 extended this, but you still needed special support, see e.g. dk-bib on CTAN. Lars Madsen, of "Avoid eqnarray!"-fame (and much else in the TeX-verse), has an excellent intro in Danish. If my memory serves me correctly, earlier β-versions had instructions on how to do hacks to get better support when writing in Danish. —Rasmus -- Lasciate ogni speranza, voi che leggete questo.
Re: [O] Citation syntax: a revised proposal
Stefan Nobis writes: jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes: From what I read in this and the previous thread, the new proposal tries more or less to reimplement BibTeX in org. No, that's wrong, not the database should be replaced. The goal is to make citations a first class citizen in the org world (so no fallback to LaTeX commands or links with special handlings are needed). I see, so in the examples provided Doe99 is only the key, org would not have to know that the author name is Doe and its year is 1999, or any other information about the citation. I thought it was more or less the equivalent of implementing natbib (http://merkel.zoneo.net/Latex/natbib.php) in org, a way to decide if I wanted textual, parenthesis or numerical citations, and thus you would have to go to the process of determining what information each citation needs, for example: an article always has an author, a book always has a publisher, but a book can have an author or an editor if each chapter has a different author, that kind of thing, among many other complicated things. Sorry for the noise. But now it is not clear to me what the actual org reference points to. If it is the actual reference, I mean the article's PDF or URL, what would you do when you need to cite a physical book? Also in this case you will not be able to produce a proper bibliography when exporting since the key cannot contain all the information needed. Now if the reference points to be entry for that reference in a database, isn't there a lot of compatibility problems if one uses one type of database vs another? Again here you will not be able to produce the bibliography when exporting -- Jorge.
Re: [O] Citation syntax: a revised proposal
Rasmus writes: > Biblatex is the gold standard. Maybe not in input-aesthetics..., but in > terms of amenability, usability and output it surely is. (No, I have > nothing to back this up). Compare the bibtex style, chicago.bst, with biblatex-chicago and note how much more closely the biblatex version approximates the Chicago Manual of Style. Also, the various multicites implemented in biblatex have made it a viable option for the humanities. Bibtex was created for use in the (hard) sciences and it lacked facilities that authors and editors in the humanities take for granted. Also, biber is required for some biblatex features that bibtex doesn't support. I haven't followed this development and am not sure what they are, though. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Citation syntax: a revised proposal
That is probably something like it. I meant sorted by year (others may prefer author), which also means looking up in the database, decorating, and then sorting, but that doesn't fundamentally change your idea. Then, from the sorted list, you have to regenerate the org-syntax and replace the original text with the new string. hard may be an overstatment. I just have the experience from org-ref that there were often corner cases that I did not anticipate, with an even simpler syntax. I would hope the new syntax and data structure make this easier, but I will reserve judgment until it exists and we can try it. I am confident some ambitious soul will set out to make a citation using every possible variation, and then want to do something like sort it, and expect it to be done correctly, and will file bug reports if it is not. If not hard, it will definitely be more difficult! Still, as long as it is possible, it is only hard one time, and then it is done. Possible is the key. That said, there is a famous statment that it is twice as hard to debug code as to write it, so if you your cleverest at writing the code you are by definition not clever enough to debug it! Like I said, this community is very clever at solving these kinds of issues, so probably it is not a reason to not try something. Rasmus writes: > John Kitchin writes: > >> They are probably minor, but for example I am not sure how easy it would >> be to sort a multicite with all of the syntax options. I guess it can be >> done, I just do not see it clearly. It may not be necessary to do this >> either. > > Out of curiosity: > > Why would this be hard? Would it amount to more than replacing identity > in the below snippet with something that gets the true author? You can > split out global pre and post note beforehand and reinsert it. I'm > probably missing something. > > (sort '((:key "foo" :pre "pre") > (:key "bar" :post "pp. 22") > (:key "baz")) > (lambda (a b) (string-collate-lessp > (funcall 'identity (plist-get a :key)) > (funcall 'identity (plist-get b :key) > > —Rasmus -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] [ox/ox-latex] Footnotes in titles
Nicolas Goaziou writes: > Rasmus writes: > >> But footnotes in titles are set with symbols, e.g. * † ‡ and so forth. >> IOW they are independent of the regular footnote counter, and don't >> consume a number. > > But then it requires to implement a special handler in every export > back-end and probably helper functions in ox.el. There are also DATE and > AUTHOR to consider. I didn't grasp the workings of the footnote functionality in ox so excuse my ignorance. Would it not be possible to allow different "counters"? (Like LaTeX). So that for org-element-document-properties (at least author and title), one would use the ox footnote functionality with an auxiliary counter. On the backend-side LaTeX would work normally but use \thanks. In html fancy entities would be used instead of arabic numbers. Same in ox-ascii. >> Footnotes in EXPORT_TITLE properties would be weird. I don't know if you >> can have that. You tell me. > > This is not possible. But then, it is asymmetric if we allow footnotes > in TITLE. OK with me. How about inline footnotes in properties? :export_title: My Title[fn::X helped a lot]. —Rasmus -- Don't panic!!!
Re: [O] Sverweis like function for orgtbl
Here is one way to do it in a code block. #+tblname: tab-data | Menge (x) | P(x) | E(x) | K(x) | Gewinn | |---+--+++-| | 0 | 20 | 0.00 | 140.00 | -140.00 | |10 | 18 | 180.00 | 180.00 | 0.00| |20 | 16 | 320.00 | 220.00 | 100.00 | |30 | 14 | 420.00 | 260.00 | 160.00 | #+BEGIN_SRC emacs-lisp :var data=tab-data :results code (let ((c4 (mapcar (lambda (x) (nth 4 x)) data)) (c2 (mapcar (lambda (x) (nth 2 x)) data))) (nth (-elem-index (-max c4) c4) c2)) #+END_SRC #+RESULTS: #+BEGIN_SRC emacs-lisp 420.0 #+END_SRC If you put the cursor on -140, and run this code, it does sort of the same thing. #+BEGIN_SRC emacs-lisp (defun jt () "find max in column, message the corresponding value in column 3." (interactive) (let ((max (string-to-number (org-table-get-field))) (row (org-table-current-line))) (while (org-table-next-row) (when (> (string-to-number (org-table-get-field)) max) (setq max (string-to-number (org-table-get-field)) ind (org-table-current-line (org-table-goto-line ind) ; columns start at 1? (org-table-goto-column 3) (message-box "%s" (org-table-get-field #+END_SRC Thorsten Grothe writes: > Dear Org-users, > > I got this table: > > | Menge (x) | P(x) | E(x) | K(x) | Gewinn | > |---+--+++-| > | 0 | 20 | 0.00 | 140.00 | -140.00 | > |10 | 18 | 180.00 | 180.00 | 0.00| > |20 | 16 | 320.00 | 220.00 | 100.00 | > |30 | 14 | 420.00 | 260.00 | 160.00 | > > and would like to find the highest value in the column "Gewinn" = 160 go > two cells left to E(x), read out the value (420) and put this in a remote > orgtbl. This is something similar to Sverweis in Excel. > > I found no predefined function for orgtbl, is it possible? > > Thanks in advance! > > Regards > Thorsten -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Citation syntax: a revised proposal
John Kitchin writes: > They are probably minor, but for example I am not sure how easy it would > be to sort a multicite with all of the syntax options. I guess it can be > done, I just do not see it clearly. It may not be necessary to do this > either. Out of curiosity: Why would this be hard? Would it amount to more than replacing identity in the below snippet with something that gets the true author? You can split out global pre and post note beforehand and reinsert it. I'm probably missing something. (sort '((:key "foo" :pre "pre") (:key "bar" :post "pp. 22") (:key "baz")) (lambda (a b) (string-collate-lessp (funcall 'identity (plist-get a :key)) (funcall 'identity (plist-get b :key) —Rasmus -- A clever person solves a problem. A wise person avoids it
Re: [O] Citation syntax: a revised proposal
John Kitchin writes: Stefan Nobis writes: Hmmm... nowadays one uses biblatex[fn:1] (with its companion biber) which makes hacking bibliography styles quite easy (in LaTeX; compared to customizing bst files). I do not think that the current discussion will lead to writing bib-styles in Lisp instead of LaTeX (at least not in the foreseeable future). This is not universally true. None of the journals we submit to accept biblatex, only bibtex. I don't know of any major science publishers that use biblatex. Same here. Journals either do not support LaTeX or support LaTeX and BibTeX. -- Jorge.
Re: [O] Citation syntax: a revised proposal
Nicolas Goaziou writes:
> [cite:subtype: ...]
>
> where "subtype" can be associated to any number of attributes, at user's
> discretion.
I like CITE:subtype for customization, where CITE is a member some set,
e.g. {cite citep/(cite) fncite citeauthor} or whatever. I like this cause
it's ∞ customizable due to the subtype.
I also like [·]{:key val}, though less so for citations. It could also be
used for "true" *inline* tasks, which would sometimes be quite nice.
> Again, I don't know if capitalization is important enough, but the added
> complexity in this case is negligible. Anyhow, I am not wedded to the
> idea.
Previously, I thought not. But since M-c is so nice I don't see why not.
[Then again, perhaps Cite could be "captured" automatically if it's after a
sentence-end (wait I see you use French spacing...! *sigh*).]
>> Aesthetically, this feels a little *too* much like BibLaTeX to me.
>
> I didn't know BibLaTeX used it at the time I suggested the idea.
> I didn't know BibLaTeX was deemed as aesthetically wrong either (why is
> it so?).
Biblatex is the gold standard. Maybe not in input-aesthetics..., but in
terms of amenability, usability and output it surely is. (No, I have
nothing to back this up).
—Rasmus
--
This message is brought to you by the department of redundant departments
Re: [O] Citation syntax: a revised proposal
Stefan Nobis writes: > jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes: > > > Hmmm... nowadays one uses biblatex[fn:1] (with its companion biber) > which makes hacking bibliography styles quite easy (in LaTeX; compared > to customizing bst files). I do not think that the current discussion > will lead to writing bib-styles in Lisp instead of LaTeX (at least not > in the foreseeable future). This is not universally true. None of the journals we submit to accept biblatex, only bibtex. I don't know of any major science publishers that use biblatex. > > [fn:1] http://ctan.org/pkg/biblatex -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Citation syntax: a revised proposal
> >> There is no question in my mind that some people will want to extend >> this, as there are just too few of the latex citation commands >> supported out of the box, especially for biblatex users (who used that >> because of limitations in bibtex ;). > > Do you think there are important commands that I missed? I did try to > make sure that all the major distinctions in biblatex were covered, > though I ignored some more esoteric things like smartcite and volcite. I think the most common ones are there. It is just that over a decade in academia has taught me that there are always people that do things another way, for some reason, including to be difficult ;) > So I suggest we let a thousand flowers bloom, and see what people come > up with, rather than trying to cut down on the verbosity up front. Also fine with me. > Hmm, OK. Let's discuss this in another thread. > >> So, overall, I am on the positive side of zero. > > Haha, leave it to a physical scientist to turn a discrete interval into > a continuous one... ;) Indeed! I could have gone with +i for I imagine it might work ;) > > Best, > Richard -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Citation syntax: a revised proposal
jorge.alfaro-muri...@yale.edu (Jorge A. Alfaro-Murillo) writes: > From what I read in this and the previous thread, the new proposal > tries more or less to reimplement BibTeX in org. No, that's wrong, not the database should be replaced. The goal is to make citations a first class citizen in the org world (so no fallback to LaTeX commands or links with special handlings are needed). > The biggest advantage of having something org/elisp native as in the > proposal would be the implementation of functions to create > bibliographies with a specific style, what Oren Patashnik called > "Bibliography-style hacking", which is very cumbersome in BibTeX > (maybe is just that I cannot read WEB/Pascal and have a strong > preference for Lisp dialects). Hmmm... nowadays one uses biblatex[fn:1] (with its companion biber) which makes hacking bibliography styles quite easy (in LaTeX; compared to customizing bst files). I do not think that the current discussion will lead to writing bib-styles in Lisp instead of LaTeX (at least not in the foreseeable future). [fn:1] http://ctan.org/pkg/biblatex -- Until the next mail..., Stefan.
Re: [O] Citation syntax: a revised proposal
Aloha Stefan, Stefan Nobis writes: > Richard Lawrence writes: > >> Rasmus writes: > >>> Parts I hate: > >>> The flag is either `@' or `&'. `@' [...] The optional hyphen (`-') > >>> Too many weird symbols that I won't be able to remember, much less explain >>> to somebody else. > >> I don't love these either, but I am not sure what a better >> alternative would be. > > I would say, just keep "@" to mark the key. The others are not really > needed. Both, "&" and "-" are better handled by a nice internal > syntax, something like > > [cite:command ...] > > or > > [cite: ... @key :part year ...] > > These internal extensions via keywords are IMHO much nicer that the > "%%(...)" variant (as a programmer I also like "%%(...)", but not as > an author). > > I think this kind of syntax (only plain "@key" or maybe "[@key]" as > shortcut and everything else within "[cite:...]") is also easier to > handle with overlays, user input helpers etc. > > Some input helper can make remembering all the options and keywords > inside [cite:...] a non-issue and overlays will render it nice in the > text. Therefore the syntax should be rather simple and regular with as > few exceptions and shorthands as sensible. This makes good sense to me. Something like [cite:command pre-note key post-note] for an individual citation is capable of carrying all the necessary information and is easy for an author to read in case overlays aren't active. IIUC, one motivation for privileging "basic" citation commands in the syntax was brevity during input. An input helper would make this motivation mostly moot and would result in a simpler syntax. Another motivation for privileging "basic" citation commands is that the syntax would then advertise the commands officially supported by Org mode. Using a simpler syntax, as Stefan suggests, would it be possible for the various ox-* files to indicate for the input helper which commands are supported? Then, the author could specify the output targets somewhere in the header and the input helper could serve up the intersection of supported commands, yielding a document portable across the indicated backends and with the richest possible set of citation commands. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Citation syntax: a revised proposal
Richard Lawrence writes: > I am OK with this if it is important, though I am a little hesitant. I don't know if it is important. Just thinking out loud. > In the last thread, you expressed concern that we not have too much > variation after the opening `[' for performance reasons, which is why I > kept all the (non-simple) citations to `[cite: ...]'. Sorry if I wasn't clear. Variations after the opening "[" are OK as long as they are contained in a _fixed_ set. Of course, the smaller the set the better. However, a customizable "cite" keyword (à la `org-add-link-type') is a no-go. If this is really needed, I already suggested [cite:subtype: ...] where "subtype" can be associated to any number of attributes, at user's discretion. > Unless you have changed your mind, I assume this means we should try not > to have very many options for this position. Expressing capitalization > here would mean there are now four options, two of which are devoted to > expressing capitalization. Is capitalization important enough to > introduce the complexity for it at *this* crucial syntactic position? Again, I don't know if capitalization is important enough, but the added complexity in this case is negligible. Anyhow, I am not wedded to the idea. > If we're trying to keep the number of variants after `[' low, we should > think carefully about what is important enough to go there. (I think > parenthetical vs. in-text does meet that bar, but I am not sure > special-case capitalization does.) OK. > Aesthetically, this feels a little *too* much like BibLaTeX to me. I didn't know BibLaTeX used it at the time I suggested the idea. I didn't know BibLaTeX was deemed as aesthetically wrong either (why is it so?). Regards,
Re: [O] Citation syntax: a revised proposal
Nicolas Goaziou writes: > John Kitchin writes: > >> I still remain somewhat on the positive side of 0. While the focus of >> these conversations has been on syntax (a necessary step to move >> forward), there has been little focus on function. > > One step at a time. It's already difficult to agree on a syntax. True enough. > >> Citations in org are /far/ more than just references in the text for >> me. They are functional links, gateways to a lot of information >> connected to the citation. My org-files are much more useful than the >> PDF manuscripts that get exported. It is hard to explain what that >> means exactly, so if you have the time check these videos out. The >> last one shows the most integrated capabilities we use. >> >> org-ref show: https://www.youtube.com/watch?v=JyvpSVl4_dg >> org-ref in action: https://www.youtube.com/watch?v=Zya8SfmCtFA >> org-ref + helm: https://www.youtube.com/watch?v=8cEb6F9AEu0 > > Very interesting. I wish we can provide some of these features out of > the box in a future release. Thanks! I would be happy to help where I can. > > I'm really puzzled here. The very point of this new syntax is to provide > at least as much information as links, while being more readable in most > cases. > > For example, I suggested > > [cite:subtype: whatever] > > which is, in my book, equivalent to > > [[subtype:whatever]] > > I think other suggestions are as capable. > > Again, the problem is not what you could do with the new syntax, but > what information it brings. AFAIU, you only need a "type" property, > which is pretty easy to provide. > > So, why do you think it would not be equivalent, feature-wise to links? They are probably minor, but for example I am not sure how easy it would be to sort a multicite with all of the syntax options. I guess it can be done, I just do not see it clearly. It may not be necessary to do this either. When on a citation, I know how to append a new citation to it, or to replace the citation at point, and I know what kind of trickery was used to enable that. I don't know how simple it would be to do that with full support of the new syntax. But again, maybe it is not necessary. It may suffice to handle the simple cases. An example of something easier might be if each @key is natively clickable. I could do away with the code that has to figure out which key you clicked on in a multicite. These are only based on my experience building org-ref, the evolution of ideas that came with it, and methods used to achieve it. I would not let this get in the way of this syntax, but it is the baggage I have thinking about it ;) These are the kinds of things I do almost every day in our scientific writing. They are all kind of small, but collectively they make it easy to do. so, it is not just about the syntax, but what the syntax makes possible to do. Real writing is messy, and not just about inserting citations. We have to edit these when students do a bad job, or when we were sloppy or incomplete. As the chief editor (a very different job than author!) I want a syntax that enables easy editing too. I am not too worried about it. Two years ago I would not have thought org-ref was even possible. A year ago I did not think it would have the features it has today. This community is very clever at solving problems. > > > Regards, -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
[O] on the fragility of export to ODT
Hello all, (I hope this is not just noise...) I use org as my main writing tool, typically for publications that I submit using LaTeX. So far, so excellent! However, I do have to export to ODT (as a means to DOC) and I find the export to be very fragile. I keep running into some strange error in long documents (which make it difficult to track down the source). The typical output to *Messages* is: , | Deleting lines with ignore heading tag | Local Ispell dictionary set to british | org-babel-exp process latex at line 185... | executing Latex code block... | Code block evaluation complete. | org-babel-exp process latex at line 244... | executing Latex code block (radarchart)... | result silenced | org-babel-exp process latex at line 245... | executing Latex code block... | Processing LaTeX file /tmp/babel-7173ozh/latex-7173lhW.tex... | PDF file produced. | Code block evaluation complete. | org-babel-exp process latex at line 460... | [...] | org-babel-exp process bibtex at line 1151... | org-babel-exp process emacs-lisp at line 1201... | LaTeX to MathML converter not available. | Formatting LaTeX using verbatim | OpenDocument export failed: FIXME: Resolve (paragraph (:begin 54129 :end 54321 ` At this point, I get very long data structures dumped to *Messages*... difficult to figure out what is wrong. It's often my mistake but tracking it down is difficult. However, more importantly, the failure is complete and nothing is exported which does not help me at all. It would be great if offending paragraphs (elements, objects, whatever) would be skipped over and the rest of the document generated. Is this possible? Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-840-g451c7b
Re: [O] Citation syntax: a revised proposal
Hi Nicolas,
Nicolas Goaziou writes:
> Time for another crazy idea. Last one on my side for today
>
> [cite ...] [(cite) ...] [Cite ...] [(Cite) ...]
>
> It should solve the :capitalize issue.
I am OK with this if it is important, though I am a little hesitant.
In the last thread, you expressed concern that we not have too much
variation after the opening `[' for performance reasons, which is why I
kept all the (non-simple) citations to `[cite: ...]'.
Unless you have changed your mind, I assume this means we should try not
to have very many options for this position. Expressing capitalization
here would mean there are now four options, two of which are devoted to
expressing capitalization. Is capitalization important enough to
introduce the complexity for it at *this* crucial syntactic position?
If we're trying to keep the number of variants after `[' low, we should
think carefully about what is important enough to go there. (I think
parenthetical vs. in-text does meet that bar, but I am not sure
special-case capitalization does.)
Aesthetically, this feels a little *too* much like BibLaTeX to me. I
would actually prefer [cite: @vanOrden60] %%(:capitalize t) or
[cite: @vanOrden60]{:capitalize t}. But like I said, I'm fine with this
if it's important.
Best,
Richard
Re: [O] Citation syntax: a revised proposal
Hi John,
I don't have time for a long reply but I wanted to express a couple
points of agreement:
John Kitchin writes:
> I think the usual suspects reftex, helm-bibtex, and probably ebib
> could be taught to output most of this syntax for whatever type, and
> they could give human readable hints about the intended format,
> e.g. intext, parenthetical, noauthor, etc... Or you could have
> dedicated commands with key completion to do that. So many options,
> this should not be an issue.
Yes, I would hope the syntax is fairly straightforward to generate.
> Presumably each &/@key will be clickable like a link, and the function
> it runs would get the key (and maybe additional info about the cite)? If
> not, that would be a show-stopper to me.
Yes, that is certainly what I had in mind. org-element may even be able
to provide support for this, so you don't have to parse the keys out
yourself in Elisp (though I think maybe this would require making keys,
in addition to complete citations, a category of object -- is that
right, Nicolas?).
> There is no question in my mind that some people will want to extend
> this, as there are just too few of the latex citation commands
> supported out of the box, especially for biblatex users (who used that
> because of limitations in bibtex ;).
Do you think there are important commands that I missed? I did try to
make sure that all the major distinctions in biblatex were covered,
though I ignored some more esoteric things like smartcite and volcite.
> My sense is the syntax may then be too verbose, and difficult to write
> exporters for and they would go back to links. That is probably a
> small number of people, and maybe I am wrong about it. I am anyway
> supportive enough to see it tried out.
I am a bit worried about this too; but one reason I suggested an
arbitrary s-expression for the %%(...) part was that it is flexible
enough to let people get very creative in making simple expressions for
particular needs. For example, I thought this was a cute hack for
genitive citations:
> @McCarthy1958 %%('s) clever use of Lisp syntax...
If you use those enough, that's a lot nicer to type and read than
> @McCarthy1958 %%(:type genitive) clever use of Lisp syntax...
So I suggest we let a thousand flowers bloom, and see what people come
up with, rather than trying to cut down on the verbosity up front.
> My final comment is that I suggest two additional things to go with this
> syntax:
>
> [bibliographystyle: some-kind-of-information-probably-unsrt/alpha/chicago]
> This would tell some backend how to style the bibliography entries. This
> does not need to be clickable (I don't know what a click would do
> anyway, at most select the style? edit the style?).
>
> [bibliography: @some-kind-of-source-probably-a-file; @maybe-more-than-one]
> This is where the keys are stored. And, it would also indicate where the
> bibliography should actually be placed. This should also be clickable,
> with a default action to just open the file that was clicked on.
>
> I prefer those to file attributes, e.g.
> #+BIBLIOGRAPHY: @some-kind-of-source-probably-a-file;
> @maybe-more-than-one
>
> I don't think that can be used to specify where a bibliography should be
> placed, and it doesn't make sense to me to use two things to specify the
> same information.
Hmm, OK. Let's discuss this in another thread.
> So, overall, I am on the positive side of zero.
Haha, leave it to a physical scientist to turn a discrete interval into
a continuous one... ;)
Best,
Richard
Re: [O] Citation syntax: a revised proposal
0. John Kitchin writes: Citations in org are /far/ more than just references in the text for me. They are functional links, gateways to a lot of information connected to the citation. My org-files are much more useful than the PDF manuscripts that get exported. I completely agree. I also would like to see if it is workable. Same here. There is nothing to lose in trying. org-ref will always be an alternative option, and if the new syntax is extendable enough it might even replace the citation links. The big advantage of org-ref is that it builds on BibTeX. From what I read in this and the previous thread, the new proposal tries more or less to reimplement BibTeX in org. (If it is not so, I apologize, because I confess that I haven't read every single email in these two veery long threads. If you plan to use BibTeX as a base, disregard the rest of the email). BibTeX is IMHO one of the best pieces of software ever created. It had a stable version from 1988 to 2010, in 2010 it was last updated, because we started to cite with long URLs (not the norm in 1988). It is something that just works as it is supposed to and has all you need for creating bibliographies. The biggest advantage of having something org/elisp native as in the proposal would be the implementation of functions to create bibliographies with a specific style, what Oren Patashnik called "Bibliography-style hacking", which is very cumbersome in BibTeX (maybe is just that I cannot read WEB/Pascal and have a strong preference for Lisp dialects). Just let me drop the mandatory reading: http://www.tex.ac.uk/tex-archive/bibliography/bibtex/base/btxdoc.pdf http://www.tex.ac.uk/tex-archive/bibliography/bibtex/base/btxhak.pdf and references therein. Best, -- Jorge.
Re: [O] Citation syntax: a revised proposal
Hi Eric, Eric S Fraga writes: > +1 emphatically. Thanks! > With respect to the bibliography database, for completeness, I would > like to see linking with org-bibtex data instead of bibtex etc. Me too, as I keep all my reference data in org-bibtex. I suggest we discuss the bibliography and other document metadata in another thread. Best, Richard
Re: [O] Citation syntax: a revised proposal
John Kitchin writes: > I still remain somewhat on the positive side of 0. While the focus of > these conversations has been on syntax (a necessary step to move > forward), there has been little focus on function. One step at a time. It's already difficult to agree on a syntax. > Citations in org are /far/ more than just references in the text for > me. They are functional links, gateways to a lot of information > connected to the citation. My org-files are much more useful than the > PDF manuscripts that get exported. It is hard to explain what that > means exactly, so if you have the time check these videos out. The > last one shows the most integrated capabilities we use. > > org-ref show: https://www.youtube.com/watch?v=JyvpSVl4_dg > org-ref in action: https://www.youtube.com/watch?v=Zya8SfmCtFA > org-ref + helm: https://www.youtube.com/watch?v=8cEb6F9AEu0 Very interesting. I wish we can provide some of these features out of the box in a future release. > These features beat the pants off every citation manager software I have > ever seen, and over the past decade I have tried a lot of them. There is > in my opinion no syntax worth giving this up for. I am only moderately > sure the proposed syntax can be used the way we use links. I am only > mildly concerned some things will be too difficult to do that are > currently possible, e.g. sorting a multcite, or rearranging them with > arrow keys. Who knows, some things might be simpler. I'm really puzzled here. The very point of this new syntax is to provide at least as much information as links, while being more readable in most cases. For example, I suggested [cite:subtype: whatever] which is, in my book, equivalent to [[subtype:whatever]] I think other suggestions are as capable. Again, the problem is not what you could do with the new syntax, but what information it brings. AFAIU, you only need a "type" property, which is pretty easy to provide. So, why do you think it would not be equivalent, feature-wise to links? Regards,
Re: [O] Separate Org file from Subtree
That's perfect John, works a treat! Thank you very much. Simon. --- On Mon, 16 Feb 2015, at 02:59 PM, John Kitchin wrote: > I think if you change (org-org-export-as-org nil t t) to > (org-org-export-as-org nil t) you would get the section content. I > didn't test it though. > > si...@psilas.com writes: > > > Thanks very much for this John. As you say, the normal export "C-c C-e > > C-s O o" does not work as expected. Your function exported the > > properties properly, but seemed to work on the visible text only and > > wouldn't export the content of headings (unless I unfold them all prior > > to import). If the article was like this: > > > > * DONE Article One > > :PROPERTIES: > > :EXPORT_TITLE: An Interesting Article > > :EXPORT_AUTHOR: Simon Jones > > :EXPORT_FILE_NAME: an-interesting-article > > :EXPORT_DATE: 2015-02-16 > > :END: > > > > Article content > > > > ** Section title > > Section content > > > > it would export as intended but without the section content. Thanks > > again for your time. > > > > Simon > > --- > > > > > > On Mon, 16 Feb 2015, at 12:54 PM, John Kitchin wrote: > >> Change :EXPORT_FILENAME: an-interesting-article to :EXPORT_FILE_NAME: > >> an-interesting-article > >> > >> Then, > >> > >> C-c C-e C-s O o > >> > >> should export to that file. I notice in the org export that the > >> properties are not getting exported, and even the headline is not > >> exported as the title though. > >> > >> Here is a function that seems to do what you want. > >> > >> #+BEGIN_SRC emacs-lisp > >> (defun export-subtree () > >> (interactive) > >> (let ((fname (concat (org-entry-get (point) "EXPORT_FILE_NAME") > >> ".org")) > >>(author (org-entry-get (point) "EXPORT_AUTHOR")) > >>(title (org-entry-get (point) "EXPORT_TITLE")) > >>(date (org-entry-get (point) "EXPORT_DATE")) > >>(content (progn (set-buffer (org-org-export-as-org nil t t)) > >>(buffer-string > >>;; warning you can delete something unintentionally > >>(when (file-exists-p fname) (delete-file fname)) > >>(find-file fname) > >>(insert "#+TITLE: " title "\n") > >>(insert "#+AUTHOR: " author "\n") > >>(insert "#+DATE: " date "\n") > >>(insert "\n" content) > >>;; remove properties drawer. Kind of hacky. > >>(goto-char (point-min)) > >>(re-search-forward ":PROPERTIES:") > >>(setf (buffer-substring > >> (org-element-property :begin (org-element-context)) > >> (org-element-property :end (org-element-context))) > >>"") > >>(save-buffer))) > >> > >> (export-subtree) > >> #+END_SRC > >> > >> si...@psilas.com writes: > >> > >> > Hi there, > >> > > >> > I think I must be missing something. > >> > > >> > I have a collection of articles in one org file (under separate > >> > headings). I can export these as a subtree using Org's normal export > >> > function as html etc., but I want to export the selected subtree as an > >> > individual org file using the properties under each heading.) > >> > > >> > In other words I want to export this subtree ... > >> > * DONE Article One > >> > :PROPERTIES: > >> > :EXPORT_TITLE: An Interesting Article > >> > :EXPORT_AUTHOR: Simon Jones > >> > :EXPORT_FILENAME: an-interesting-article > >> > :EXPORT_DATE: 2015-02-16 > >> > :END: > >> > > >> > Article content > >> > > >> > into an Org file entitled 'an-interesting-article.org' that looks like > >> > this ... > >> > > >> > #+TITLE: An Interesting Article > >> > #+AUTHOR: Simon Jones > >> > #+DATE: 2015-02-16 > >> > > >> > Article content... > >> > > >> > Can anyone help me with this? I'm very sorry if I'm missing something > >> > obvious. > >> > > >> > Simon. > >> > >> -- > >> Professor John Kitchin > >> Doherty Hall A207F > >> Department of Chemical Engineering > >> Carnegie Mellon University > >> Pittsburgh, PA 15213 > >> 412-268-7803 > >> @johnkitchin > >> http://kitchingroup.cheme.cmu.edu > > -- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu
[O] Sverweis like function for orgtbl
Dear Org-users, I got this table: | Menge (x) | P(x) | E(x) | K(x) | Gewinn | |---+--+++-| | 0 | 20 | 0.00 | 140.00 | -140.00 | |10 | 18 | 180.00 | 180.00 | 0.00| |20 | 16 | 320.00 | 220.00 | 100.00 | |30 | 14 | 420.00 | 260.00 | 160.00 | and would like to find the highest value in the column "Gewinn" = 160 go two cells left to E(x), read out the value (420) and put this in a remote orgtbl. This is something similar to Sverweis in Excel. I found no predefined function for orgtbl, is it possible? Thanks in advance! Regards Thorsten
Re: [O] Separate Org file from Subtree
I think if you change (org-org-export-as-org nil t t) to (org-org-export-as-org nil t) you would get the section content. I didn't test it though. si...@psilas.com writes: > Thanks very much for this John. As you say, the normal export "C-c C-e > C-s O o" does not work as expected. Your function exported the > properties properly, but seemed to work on the visible text only and > wouldn't export the content of headings (unless I unfold them all prior > to import). If the article was like this: > > * DONE Article One > :PROPERTIES: > :EXPORT_TITLE: An Interesting Article > :EXPORT_AUTHOR: Simon Jones > :EXPORT_FILE_NAME: an-interesting-article > :EXPORT_DATE: 2015-02-16 > :END: > > Article content > > ** Section title > Section content > > it would export as intended but without the section content. Thanks > again for your time. > > Simon > --- > > > On Mon, 16 Feb 2015, at 12:54 PM, John Kitchin wrote: >> Change :EXPORT_FILENAME: an-interesting-article to :EXPORT_FILE_NAME: >> an-interesting-article >> >> Then, >> >> C-c C-e C-s O o >> >> should export to that file. I notice in the org export that the >> properties are not getting exported, and even the headline is not >> exported as the title though. >> >> Here is a function that seems to do what you want. >> >> #+BEGIN_SRC emacs-lisp >> (defun export-subtree () >> (interactive) >> (let ((fname (concat (org-entry-get (point) "EXPORT_FILE_NAME") >> ".org")) >>(author (org-entry-get (point) "EXPORT_AUTHOR")) >>(title (org-entry-get (point) "EXPORT_TITLE")) >>(date (org-entry-get (point) "EXPORT_DATE")) >>(content (progn (set-buffer (org-org-export-as-org nil t t)) >>(buffer-string >>;; warning you can delete something unintentionally >>(when (file-exists-p fname) (delete-file fname)) >>(find-file fname) >>(insert "#+TITLE: " title "\n") >>(insert "#+AUTHOR: " author "\n") >>(insert "#+DATE: " date "\n") >>(insert "\n" content) >>;; remove properties drawer. Kind of hacky. >>(goto-char (point-min)) >>(re-search-forward ":PROPERTIES:") >>(setf (buffer-substring >> (org-element-property :begin (org-element-context)) >> (org-element-property :end (org-element-context))) >>"") >>(save-buffer))) >> >> (export-subtree) >> #+END_SRC >> >> si...@psilas.com writes: >> >> > Hi there, >> > >> > I think I must be missing something. >> > >> > I have a collection of articles in one org file (under separate >> > headings). I can export these as a subtree using Org's normal export >> > function as html etc., but I want to export the selected subtree as an >> > individual org file using the properties under each heading.) >> > >> > In other words I want to export this subtree ... >> > * DONE Article One >> > :PROPERTIES: >> > :EXPORT_TITLE: An Interesting Article >> > :EXPORT_AUTHOR: Simon Jones >> > :EXPORT_FILENAME: an-interesting-article >> > :EXPORT_DATE: 2015-02-16 >> > :END: >> > >> > Article content >> > >> > into an Org file entitled 'an-interesting-article.org' that looks like >> > this ... >> > >> > #+TITLE: An Interesting Article >> > #+AUTHOR: Simon Jones >> > #+DATE: 2015-02-16 >> > >> > Article content... >> > >> > Can anyone help me with this? I'm very sorry if I'm missing something >> > obvious. >> > >> > Simon. >> >> -- >> Professor John Kitchin >> Doherty Hall A207F >> Department of Chemical Engineering >> Carnegie Mellon University >> Pittsburgh, PA 15213 >> 412-268-7803 >> @johnkitchin >> http://kitchingroup.cheme.cmu.edu -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] key binding for org-inlinetask-insert-task has gone missing?
Hello all, Please ignore my previous email. I have rebuilt org and restarted emacs and everything is back to normal. I don't know why a particular key binding disappeared but maybe it was a cosmic ray incident :) [[http://xkcd.com/378/]] Sorry for the noise. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-840-g451c7b
Re: [O] Separate Org file from Subtree
Thanks very much for this John. As you say, the normal export "C-c C-e C-s O o" does not work as expected. Your function exported the properties properly, but seemed to work on the visible text only and wouldn't export the content of headings (unless I unfold them all prior to import). If the article was like this: * DONE Article One :PROPERTIES: :EXPORT_TITLE: An Interesting Article :EXPORT_AUTHOR: Simon Jones :EXPORT_FILE_NAME: an-interesting-article :EXPORT_DATE: 2015-02-16 :END: Article content ** Section title Section content it would export as intended but without the section content. Thanks again for your time. Simon --- On Mon, 16 Feb 2015, at 12:54 PM, John Kitchin wrote: > Change :EXPORT_FILENAME: an-interesting-article to :EXPORT_FILE_NAME: > an-interesting-article > > Then, > > C-c C-e C-s O o > > should export to that file. I notice in the org export that the > properties are not getting exported, and even the headline is not > exported as the title though. > > Here is a function that seems to do what you want. > > #+BEGIN_SRC emacs-lisp > (defun export-subtree () > (interactive) > (let ((fname (concat (org-entry-get (point) "EXPORT_FILE_NAME") > ".org")) >(author (org-entry-get (point) "EXPORT_AUTHOR")) >(title (org-entry-get (point) "EXPORT_TITLE")) >(date (org-entry-get (point) "EXPORT_DATE")) >(content (progn (set-buffer (org-org-export-as-org nil t t)) >(buffer-string >;; warning you can delete something unintentionally >(when (file-exists-p fname) (delete-file fname)) >(find-file fname) >(insert "#+TITLE: " title "\n") >(insert "#+AUTHOR: " author "\n") >(insert "#+DATE: " date "\n") >(insert "\n" content) >;; remove properties drawer. Kind of hacky. >(goto-char (point-min)) >(re-search-forward ":PROPERTIES:") >(setf (buffer-substring > (org-element-property :begin (org-element-context)) > (org-element-property :end (org-element-context))) >"") >(save-buffer))) > > (export-subtree) > #+END_SRC > > si...@psilas.com writes: > > > Hi there, > > > > I think I must be missing something. > > > > I have a collection of articles in one org file (under separate > > headings). I can export these as a subtree using Org's normal export > > function as html etc., but I want to export the selected subtree as an > > individual org file using the properties under each heading.) > > > > In other words I want to export this subtree ... > > * DONE Article One > > :PROPERTIES: > > :EXPORT_TITLE: An Interesting Article > > :EXPORT_AUTHOR: Simon Jones > > :EXPORT_FILENAME: an-interesting-article > > :EXPORT_DATE: 2015-02-16 > > :END: > > > > Article content > > > > into an Org file entitled 'an-interesting-article.org' that looks like > > this ... > > > > #+TITLE: An Interesting Article > > #+AUTHOR: Simon Jones > > #+DATE: 2015-02-16 > > > > Article content... > > > > Can anyone help me with this? I'm very sorry if I'm missing something > > obvious. > > > > Simon. > > -- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu
Re: [O] Citation syntax: a revised proposal
Eric S Fraga writes: > On Saturday, 14 Feb 2015 at 18:29, Richard Lawrence wrote: >> Hi everyone, >> >> Since discussion seems to have petered out on the previous thread (see: >> http://thread.gmane.org/gmane.emacs.orgmode/94524), I took some time to >> go back over the discussion and write up a concrete proposal for >> citation syntax. > > +1 emphatically. I still remain somewhat on the positive side of 0. While the focus of these conversations has been on syntax (a necessary step to move forward), there has been little focus on function. Citations in org are /far/ more than just references in the text for me. They are functional links, gateways to a lot of information connected to the citation. My org-files are much more useful than the PDF manuscripts that get exported. It is hard to explain what that means exactly, so if you have the time check these videos out. The last one shows the most integrated capabilities we use. org-ref show: https://www.youtube.com/watch?v=JyvpSVl4_dg org-ref in action: https://www.youtube.com/watch?v=Zya8SfmCtFA org-ref + helm: https://www.youtube.com/watch?v=8cEb6F9AEu0 These features beat the pants off every citation manager software I have ever seen, and over the past decade I have tried a lot of them. There is in my opinion no syntax worth giving this up for. I am only moderately sure the proposed syntax can be used the way we use links. I am only mildly concerned some things will be too difficult to do that are currently possible, e.g. sorting a multcite, or rearranging them with arrow keys. Who knows, some things might be simpler. > I would like to see something along these lines implemented so we can > "suck it and see"... I also would like to see if it is workable. There is nothing to lose in trying. org-ref will always be an alternative option, and if the new syntax is extendable enough it might even replace the citation links. > For my use case, you've covered everything and, as John Kitchin says, > most cite insertions could be automated through appropriate code and key > bindings but, very importantly, common uses are quite straightforward to > type directly. > > With respect to the bibliography database, for completeness, I would > like to see linking with org-bibtex data instead of bibtex etc. I think we can come up with a reasonable, user-customizable api that would support multiple data sources. A user would customize the click and export function. There might even be simple out of the box default functions for org-bibtex and bibtex, and zotero through zotxt. For the first two, the click function could just open the entry in the bibliography file. > > Thanks, > eric -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
[O] orgmode-contacts "wrong type arguments"
Presumably this is related to my having upgraded to:
Org-mode version 8.2.10 (8.2.10-33-g880a2b-elpa)
GNU Emacs 25.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.9) of
2015-02-10 on localhost.localdomain
I use org-contacts[1] to autofill addresses in GNUs. Normally can use
"+CATEGORY" to add all names in a category; but now that particular
functionality seems to be broken (although the package is otherwise
functional). In my efforts to improve my elisp, can anyone tell me why the code
doesn't work, and what might have changed to cause it to break?
Error:
completion-in-region: Wrong type argument: listp, #("NAME ,
NAME , NAME , NAME " 0
15 (fontified nil org-category "contacts") 44 65 (fontified nil org-category
"contacts") 88 99 (fontified nil org-category "contacts") 127 141 (fontified
nil org-category "contacts"))
Footnotes:
[1] https://julien.danjou.info/projects/emacs-packages#org-contacts
Re: [O] Citation syntax: a revised proposal
+1 from me too, observing from the sidelines but also wanting to be able to handle citations. Bill On 16 February 2015, Eric S Fraga wrote: On Saturday, 14 Feb 2015 at 18:29, Richard Lawrence wrote: Hi everyone, Since discussion seems to have petered out on the previous thread (see: http://thread.gmane.org/gmane.emacs.orgmode/94524), I took some time to go back over the discussion and write up a concrete proposal for citation syntax. +1 emphatically. I would like to see something along these lines implemented so we can "suck it and see"... For my use case, you've covered everything and, as John Kitchin says, most cite insertions could be automated through appropriate code and key bindings but, very importantly, common uses are quite straightforward to type directly. With respect to the bibliography database, for completeness, I would like to see linking with org-bibtex data instead of bibtex etc. Thanks, eric -- William Denton ↔ Toronto, Canada ↔ https://www.miskatonic.org/
Re: [O] Separate Org file from Subtree
Change :EXPORT_FILENAME: an-interesting-article to :EXPORT_FILE_NAME: an-interesting-article Then, C-c C-e C-s O o should export to that file. I notice in the org export that the properties are not getting exported, and even the headline is not exported as the title though. Here is a function that seems to do what you want. #+BEGIN_SRC emacs-lisp (defun export-subtree () (interactive) (let ((fname (concat (org-entry-get (point) "EXPORT_FILE_NAME") ".org")) (author (org-entry-get (point) "EXPORT_AUTHOR")) (title (org-entry-get (point) "EXPORT_TITLE")) (date (org-entry-get (point) "EXPORT_DATE")) (content (progn (set-buffer (org-org-export-as-org nil t t)) (buffer-string ;; warning you can delete something unintentionally (when (file-exists-p fname) (delete-file fname)) (find-file fname) (insert "#+TITLE: " title "\n") (insert "#+AUTHOR: " author "\n") (insert "#+DATE: " date "\n") (insert "\n" content) ;; remove properties drawer. Kind of hacky. (goto-char (point-min)) (re-search-forward ":PROPERTIES:") (setf (buffer-substring (org-element-property :begin (org-element-context)) (org-element-property :end (org-element-context))) "") (save-buffer))) (export-subtree) #+END_SRC si...@psilas.com writes: > Hi there, > > I think I must be missing something. > > I have a collection of articles in one org file (under separate > headings). I can export these as a subtree using Org's normal export > function as html etc., but I want to export the selected subtree as an > individual org file using the properties under each heading.) > > In other words I want to export this subtree ... > * DONE Article One > :PROPERTIES: > :EXPORT_TITLE: An Interesting Article > :EXPORT_AUTHOR: Simon Jones > :EXPORT_FILENAME: an-interesting-article > :EXPORT_DATE: 2015-02-16 > :END: > > Article content > > into an Org file entitled 'an-interesting-article.org' that looks like > this ... > > #+TITLE: An Interesting Article > #+AUTHOR: Simon Jones > #+DATE: 2015-02-16 > > Article content... > > Can anyone help me with this? I'm very sorry if I'm missing something > obvious. > > Simon. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
[O] (org-use-fast-tag-selection (quote auto)) - non ASCII characters shown as e.g. [\200] and other problems
I have set up only one persistent tag set with a key character like this:
(org-tag-persistent-alist (quote (("@i_shopping" . 105
There are no file based #+TAGS in any of org files.
I also like to have access to all tags in all files, so I set this up:
(org-complete-tags-always-offer-all-agenda-tags t)
Finally I'd like to have a fast selection splash screen:
(org-use-fast-tag-selection (quote auto))
Now the problems:
Running C-q in an org file on a heading shows a fast selection splash
window:
1. The main problem is that the assigned fast pick characters are not only
'a-z', but also non-ASCII characters which are shown as:
- [\200] tagname1
- [\204] tagname2
- etc
There seems to be no way to select tagname1 or tagname2.
2. With all the above variables unchanged hitting the TAB here for
selection of tags in the minibuffer only allows tags already in the file,
ignoring the (org-complete-tags-always-offer-all-agenda-tags t) variable.
Disabling (org-use-fast-tag-selection (quote auto)) and hitting TAB after
C-q actually shows the selection of all tags in a Completions buffer as
expected, except in the Capture Buffer.
3. In a Capture Buffer, in addition to problem 1., and problem 2., TAB
does not show a full list of tags in the Completions buffer (with the
disabled fast select as in Problem 2. above). However, typing a first
letter of a tag and then TAB will list all tags beginning with that letter
in all the org files and not only org-tag-persistent-alist.
So, fast select seems broken.
I would expect it behave like this:
1. having (org-complete-tags-always-offer-all-agenda-tags t) and
(org-use-fast-tag-selection
(quote auto)) should limit the tags selection to ASCII only characters or
offer double character selection like [aa]-[zz] if there are more tags that
az permits. Use numbers perhaps too?.
2. If 1. is not possible then perhaps limit the characters to az and
leaving other tags out of the fast select but allow TAB to choose all tags
in all org files using org-ido?
3. what is the point of 'auto' in (org-use-fast-tag-selection (quote
auto)) if it does exactly the same thing if set to (org-use-fast-tag-selection
(quote always))?
I'm forced currently to disable (org-use-fast-tag-selection (quote auto))
setting it to (org-use-fast-tag-selection (quote never)) and use the
Completions buffer, which seems to work more consistently.
Re: [O] Citation syntax: a revised proposal
On Saturday, 14 Feb 2015 at 18:29, Richard Lawrence wrote: > Hi everyone, > > Since discussion seems to have petered out on the previous thread (see: > http://thread.gmane.org/gmane.emacs.orgmode/94524), I took some time to > go back over the discussion and write up a concrete proposal for > citation syntax. +1 emphatically. I would like to see something along these lines implemented so we can "suck it and see"... For my use case, you've covered everything and, as John Kitchin says, most cite insertions could be automated through appropriate code and key bindings but, very importantly, common uses are quite straightforward to type directly. With respect to the bibliography database, for completeness, I would like to see linking with org-bibtex data instead of bibtex etc. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-834-g836d9d
Re: [O] org-time-stamp adds "repeater" where there is none.
Nicolas Goaziou writes: >> <2015-02-13 ven.> (10h-13h) >> >> Hiting C-c . RET with point on the timestamp gives >> <2015-02-13 ven. -13h> (10h-13h) >> >> which is not expected. > > It should now be fixed. > Thanks, works great so far (unlike my own patch, which would fail in some situations). -- Nicolas
[O] Separate Org file from Subtree
Hi there, I think I must be missing something. I have a collection of articles in one org file (under separate headings). I can export these as a subtree using Org's normal export function as html etc., but I want to export the selected subtree as an individual org file using the properties under each heading.) In other words I want to export this subtree ... * DONE Article One :PROPERTIES: :EXPORT_TITLE: An Interesting Article :EXPORT_AUTHOR: Simon Jones :EXPORT_FILENAME: an-interesting-article :EXPORT_DATE: 2015-02-16 :END: Article content into an Org file entitled 'an-interesting-article.org' that looks like this ... #+TITLE: An Interesting Article #+AUTHOR: Simon Jones #+DATE: 2015-02-16 Article content... Can anyone help me with this? I'm very sorry if I'm missing something obvious. Simon.
Re: [O] Citation syntax: a revised proposal
Matt Price writes: > I am generally much more positive than Thomas, being, for the most part, > ecstatic at the thought of a built-in citation syntax which will make > citations in org workable for bumbling nonprogrammers like myself. > > However, I agree that the distinction between parenthetical and footnotes > citations is unhelpful for me. Whenever I switch between Chicago and APA, > for instance, zotero converts my footnotes to parenthetical expressions. > To me this seems an essential feature. Maybe Richard stepped back on this, but I think at some point the consensus was that you'd have two main cite types, namely @· and [@·] which can be mapped to whatever, e.g. @· → textcite by default and [@·] → \parencite. Then the switch would be. #+INLINE-CITE: textcite #+SQUARE-CITE: parencite —Rasmus -- Governments should be afraid of their people
Re: [O] Citation syntax: a revised proposal
Nicolas Goaziou writes: > Time for another crazy idea. Last one on my side for today > [cite ...] [(cite) ...] [Cite ...] [(Cite) ...] > It should solve the :capitalize issue. +1 I really like it - even when looking at the org file with something weird like vim, it's very clear and intuitive what's meant. -- Until the next mail..., Stefan.
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Hello, Nikolai Weibull writes: > Sorry for the late reply. Here’s a patch that should work: Thank you. Could you provide an appropriate commit message and send it using git format-patch? If you haven't signed FSF papers yet, you also need to add TINYCHANGE at the end of the commit message. Regards, -- Nicolas Goaziou
Re: [O] Why not push?
Hi Marcin, Marcin Borkowski wrote: > I don't want to be nitpicking, but I'm just curious. I'm looking at the > function `org-split-string'. It uses (two times) the following > construction: > > (setq list (cons (something) list)) > > Is there any particular reason for not using `push' there? IIUC, Emacs developers did not like needing (require 'cl) in the packages' code base. Not sure why (they did not like it, or why they did not integrate such handy functions in the Emacs core). And it seems to have changed. They even have a lot of `cl-*' functions now. Though, for whatever reason, they don't have `cl-push', but well `cl-pushnew'... Not all that clear to me. Best regards, Seb -- Sebastien Vauban
Re: [O] Citation syntax: a revised proposal
Hello,
Matt Price writes:
> However, I agree that the distinction between parenthetical and footnotes
> citations is unhelpful for me. Whenever I switch between Chicago and APA,
> for instance, zotero converts my footnotes to parenthetical expressions.
> To me this seems an essential feature.
There is no distinction between parenthetical and footnotes citations in
the syntax. Richard showed that citations can be included in footnote
definitions, but that's about it.
AFAICT, nothing prevents you from writing
A citation[cite ... @key ...]{latex :type footnotecite} within
a paragraph.
and let "ox-latex" turn it into a footnote citation for you.
Regards,
--
Nicolas Goaziou
Re: [O] Citation syntax: a revised proposal
Richard Lawrence writes: > Rasmus writes: >> Parts I hate: >> The flag is either `@' or `&'. `@' [...] The optional hyphen (`-') >> Too many weird symbols that I won't be able to remember, much less explain >> to somebody else. > I don't love these either, but I am not sure what a better > alternative would be. I would say, just keep "@" to mark the key. The others are not really needed. Both, "&" and "-" are better handled by a nice internal syntax, something like [cite:command ...] or [cite: ... @key :part year ...] These internal extensions via keywords are IMHO much nicer that the "%%(...)" variant (as a programmer I also like "%%(...)", but not as an author). I think this kind of syntax (only plain "@key" or maybe "[@key]" as shortcut and everything else within "[cite:...]") is also easier to handle with overlays, user input helpers etc. Some input helper can make remembering all the options and keywords inside [cite:...] a non-issue and overlays will render it nice in the text. Therefore the syntax should be rather simple and regular with as few exceptions and shorthands as sensible. -- Until the next mail..., Stefan.
