[O] Comment on Org Export Reference
I've been working on an export backend for personal use, and I find the documentation on worg to be... not quite what I need. In the spirit of suggesting an avenue for improvement, then: The page covers a lot of details, but less in the way of context. For instance, the toolbox is documented extensively, but I didn't see a comprehensive list of the transcoding functions that a backend should implement, nor details of these functions' inputs, nor recommendations for handling elements that aren't obvious (tags, links, footnotes...). In my first attempt, I even left out ox-*-template -- I had no idea what the template was or its importance! (It is actually sort of covered on worg, but it's buried in a quoted docstring with nothing to highlight its rather crucial nature.) I've had to infer these from ox-ascii.el, which also covers a lot of cases that aren't relevant to this exporter, making it hard to guess what is strictly necessary. The result for me has been rather remarkable amounts of wasted time. I also wonder about documenting functions without documenting their arguments. Like, yesterday I was trying to use org-export-get-parent: first, find out that the function exists on worg, then switch to emacs and C-h f it to find out *really* how to use it. Why C-h f? Because the worg page says *nothing* about the arguments! At the very least, another section needs to be added, listing the elements that need to be transcoded. Also some common cases might be nice, e.g., what's the canonical way to access tags? Properties? Typical cases for links that you wouldn't think of unless you already know what you're doing (but if you already knew what you're doing, you wouldn't be scouring the reference)? I'll add that, despite some painful false starts, I've got a shocking amount of the elements working already. Some, that I might have expected to be hard (e.g., plain lists) were close to trivially easy! So I'd say the exporter design is a thing of beauty -- serious applause for this -- it's just that the entry point involves too much puzzling over source code and not enough well-organized explanation. hjh Sent with AquaMail for Android http://www.aqua-mail.com
[O] Babel questions for finalising Processing support
Greetings. My implementation of Processing support in Babel is proceeding really well! I have now both external viewing of sketches and export to html (sketches drawn by browser) working. There are a number of details to fix, though. 1. When editing Processing code with C-c ' I get an error from processing-mode. Editing with C-c ' works just fine, but the error is annoying. It seems to me the error is caused by the fact that processing-mode refers to buffer-file-name, which is not valid in a temporary buffer. Any ideas on how to fix this inside org? (Wouldn't want to get involved with processing-mode if it can be avoided.) Is there for example a hook I could use to set buffer-file-name to some temporary value? 2. When processing code is executed with C-c C-c, it shows the sketch in an external viewer. When exported, the results are html code. To this end I have set default header arguments for Processing to be ":results html" and ":exports results". With C-c C-c execution, org-babel-execute:processing returns nil. This works fine otherwise, but even C-c C-c execution produces an empty results section: #+RESULTS: #+BEGIN_HTML #+END_HTML This is a nuisance, since C-c C-c execution always also changes the current file (even though nothing changes). Is there a way to avoid this? 3. In ob-processing.el I (require 'ob). However, to avoid a compiler warning about a free variable I still need to declare (eval-when-compile (defvar org-babel-temporary-directory)) Is this ok? 4. Processing support in Babel will depend on processing2-emacs module, which contains the function processing-sketch-run. Again, to avoid compiler warnings, I am declaring this by (declare-function processing-sketch-run "processing-mode.el" nil) Is this ok? Jarmo
Re: [O] Comment on Org Export Reference
Hi James, James Harkins writes: > I've been working on an export backend for personal use, and I find > the documentation on worg to be... not quite what I need. In the > spirit of suggesting an avenue for improvement, then: I'm happy you found of ox and org-element useful. Nicolas' work is indeed very pleasant to work with, as you found out. It would be great if you would address the documentation issues that you raised in form of, preferably, a patch to org.texi, or alternatively an addition to Worg. Thanks, Rasmus -- Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Richard Lawrence writes: > I dropped the second underscore when I was writing the grammar. Thanks, > Vaisheeswaran, for noticing. Nicolas, IMO we should update the parser > to allow underscores in keys (including at the final character, I > guess). Done in ab7ff4034e8cd67ae5b5e2cfddfee87082228801. Regards,
Re: [O] Re-marking agenda entries, with advice on org-agenda-bulk-action in .emacs
Hello, Robert Pluim writes: > Hi, there's a small issue with the texi description of this > feature. Fixed as follows: > > * org.texi (Agenda commands): Correct reference to > org-agenda-persistent-marks Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [ox-ascii, bug?] links are wrapped in [·]
Hello, Rasmus writes: > Try the following: > > (with-temp-buffer > (require 'ox-ascii) > (insert "http://orgmode.org";) > (org-ascii-export-as-ascii nil nil nil t)) > > This will output [http://orgmode.org]. I don't think that www-links > should be treated the same as "random links" here. Maybe we could check > the raw link against a regexp for hyperlinks? This is a feature. Every link is put into square brackets. You can easily remove them with a filter, using `org-plain-link-re'. Regards, -- Nicolas Goaziou
Re: [O] Bug: org-habit treats all repeat tasks as ".+" type [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
Hello, 何利勇 writes: > It looks like org-habit only handle the ".+" repeater correctly, though > the document says it supports ".+", "++" and "+". > > For example, when create agenda for the following org content. > > * TODO Test_+ > SCHEDULED: <2015-03-02 Mon +1w> > - State "DONE" from "TODO" [2015-02-23 Mon 10:56] > - State "DONE" from "TODO" [2015-02-16 Mon 10:56] > - State "DONE" from "TODO" [2015-02-10 Tue 10:56] > - State "DONE" from "READY" [2015-02-02 Mon 10:56] > :PROPERTIES: > :STYLE:habit > :LAST_REPEAT: [2015-02-23 Mon 10:56] > :ID: e960c39e-4f92-4ef0-a5ee-a4d3fcfd26bf > :END: > > * TODO Test_++ > SCHEDULED: <2015-03-02 Mon ++1w> > - State "DONE" from "TODO" [2015-02-23 Mon 10:56] > - State "DONE" from "TODO" [2015-02-15 Sun 10:56] > - State "DONE" from "READY" [2015-02-02 Mon 10:56] > :PROPERTIES: > :STYLE:habit > :LAST_REPEAT: [2015-02-23 Mon 10:56] > :END: I don't think this bug still exists in a recent Org. Could you update Org (preferably to development version) and test it again? Note that in development version, entries above are somewhat invalid because properties drawer must be located just after "SCHEDULED" line. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Here is a patch I want to add to org.el……
Andreas Leha writes: > I see. I did not read carefully enough. Fine with me as well. I pushed it in 1362c2d22b037f43bd9f5a42c01c7ca8300d14cd (master). Thanks again for the feedback. Regards,
Re: [O] Comment on Org Export Reference
Hello, James Harkins writes: > The page covers a lot of details, but less in the way of context. For > instance, the toolbox is documented extensively, but I didn't see > a comprehensive list of the transcoding functions that a backend > should implement There is no rule about what a back-end should implement (besides template). Anyway full list of supported elements and objects, along with all associated properties is in "Org Element API" document[fn:1]. > nor details of these functions' inputs, nor recommendations for > handling elements that aren't obvious (tags, links, footnotes...). I'm not sure there's a general rule to handle them. However I tried to give real examples on how to use some tools in > I've had to infer these from ox-ascii.el, which also covers a lot of > cases that aren't relevant to this exporter, making it hard to guess > what is strictly necessary. The result for me has been rather > remarkable amounts of wasted time. At some point, I wanted to write a tutorial on how to create a back-end from scratch. I even chose Markdown to do it. Unfortunately, I wrote "ox-md.el" and, for various reasons, skipped the tutorial. Anyway, such a tutorial is more than welcome, if you want to write one. > I also wonder about documenting functions without documenting their > arguments. Like, yesterday I was trying to use org-export-get-parent: > first, find out that the function exists on worg, then switch to emacs > and C-h f it to find out *really* how to use it. Why C-h f? Because > the worg page says *nothing* about the arguments! Tools section could indeed list arguments required for each tool. However, I expect users to use Emacs internal documentation first. Anyway, patch welcome. > At the very least, another section needs to be added, listing the > elements that need to be transcoded. See above. > Also some common cases might be nice, e.g., what's the canonical way > to access tags? Properties? Typical cases for links that you wouldn't > think of unless you already know what you're doing (but if you already > knew what you're doing, you wouldn't be scouring the reference)? There's a tool named `org-export-get-tags' with an example on how to use it already. Likewise, there's a tool named `org-export-get-node-property'. However, it doesn't contain an example. > I'll add that, despite some painful false starts, I've got a shocking > amount of the elements working already. Some, that I might have > expected to be hard (e.g., plain lists) were close to trivially easy! > So I'd say the exporter design is a thing of beauty -- serious > applause for this -- Thank you. > it's just that the entry point involves too much puzzling over source > code and not enough well-organized explanation. Help welcome. Also, do not hesitate to ask questions on the ML. Regards, [fn:1] http://orgmode.org/worg/dev/org-element-api.html -- Nicolas Goaziou
Re: [O] Here is a patch I want to add to org.el……
Hi Nicolas, Nicolas Goaziou writes: > Andreas Leha writes: > >> I see. I did not read carefully enough. Fine with me as well. > > I pushed it in 1362c2d22b037f43bd9f5a42c01c7ca8300d14cd (master). Thanks > again for the feedback. > Thanks! A big improvement for me. Andreas
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Nicolas Goaziou writes: > Richard Lawrence writes: > >> I dropped the second underscore when I was writing the grammar. Thanks, >> Vaisheeswaran, for noticing. Nicolas, IMO we should update the parser >> to allow underscores in keys (including at the final character, I >> guess). > > Done in ab7ff4034e8cd67ae5b5e2cfddfee87082228801. This is also not captured: [cite:@Röntgen]. Why limit org-element--citation-key-re to a-z? —Rasmus -- Together we'll stand, divided we'll fall
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
On Friday 06 March 2015 04:19 PM, Nicolas Goaziou wrote:
> Richard Lawrence writes:
>
>> I dropped the second underscore when I was writing the grammar. Thanks,
>> Vaisheeswaran, for noticing. Nicolas, IMO we should update the parser
>> to allow underscores in keys (including at the final character, I
>> guess).
>
> Done in ab7ff4034e8cd67ae5b5e2cfddfee87082228801.
The following combination works when passed through the LaTeX/PDF
exporter. It doesn't work when the cite syntax is switched to the new
one.
\cite{center_for_history_and_new_media_zotero_}
@misc{center_for_history_and_new_media_zotero_,
title = {Zotero Quick Start Guide},
url = {http://zotero.org/support/quick_start_guide},
author = {{Center for History and New Media}},
annote = {Welcome to {Zotero!View} the Quick Start Guide to learn how
to begin collecting, managing, citing, and sharing your research
{sources.Thanks} for installing Zotero.}
}
[O] Zotero csl file that uses parenthetical style for citations
I am trying to locate a Zotero csl file that produces parenthetical style -- Author (Date) -- for citations[1]. The primer[2] uses the term "in-text" to refer to what this mailing list has been designating as "parenthetical" style. I want to see an "off-the-shelf" csl style file, that uses parenthetical style. [1] https://www.zotero.org/styles [2] http://docs.citationstyles.org/en/latest/primer.html#in-text-styles
Re: [O] Zotero csl file that uses parenthetical style for citations
On Friday 06 March 2015 06:33 PM, Vaidheeswaran C wrote: > I am trying to locate a Zotero csl file that produces parenthetical > style -- Author (Date) -- for citations[1]. The primer[2] uses the > term "in-text" to refer to what this mailing list has been designating > as "parenthetical" style. > > I want to see an "off-the-shelf" csl style file, that uses > parenthetical style. > > [1] https://www.zotero.org/styles > [2] http://docs.citationstyles.org/en/latest/primer.html#in-text-styles When I say this, I am really asking for counter-example. If parenthetical styles aren't hard to create and if they are absent from style repo, I would consider it "conspicuous by absence". What grounds would justify such a notable absence. If an off-the-shelf csl file doesn't produce parenthetical styles, how would a Org user go about producing parenthetical styles. As I said before, I am approaching this whole thread from a "tools" perspective.
Re: [O] Zotero csl file that uses parenthetical style for citations
Vaidheeswaran C writes: > I am approaching this whole thread from a "tools" perspective. https://www.ctan.org/pkg/biblatex http://www.ctan.org/pkg/biblatex-chicago http://www.ctan.org/pkg/biblatex-apa http://www.ctan.org/pkg/natbib http://www.ctan.org/pkg/chicago http://www.ctan.org/pkg/harvard -- Summon the Mothership!
Re: [O] Zotero csl file that uses parenthetical style for citations
Vaidheeswaran C writes: > I am trying to locate a Zotero csl file that produces parenthetical > style -- Author (Date) -- for citations[1]. The primer[2] uses the > term "in-text" to refer to what this mailing list has been designating > as "parenthetical" style. Author-date a la biblatex have two primary calls: \texcite, e.g. A () and \parencite, e.g. (A ). You can also cite just the author or just the year. Based on this¹ discussion, I'm not sure CSL supports both within a single style file. Perhaps several CSL files could be combined to support this workflow, e.g. via citeproc-java's command line program. > I want to see an "off-the-shelf" csl style file, that uses > parenthetical style. Maybe this: https://github.com/citation-style-language/styles/blob/master/chicago-author-date.csl —Rasmus Footnotes: ¹ http://citationstyles.org/styles/, section "Suppress Author" -- Warning: Everything saved will be lost
Re: [O] Comment on Org Export Reference
On 2015-03-06, at 09:55, James Harkins wrote: > I've been working on an export backend for personal use, and I find the > documentation on worg to be... not quite what I need. In the spirit of In fact, studying the sources for existing exporters seems to be the best way to learn that stuff. > suggesting an avenue for improvement, then: > > The page covers a lot of details, but less in the way of context. For > instance, the toolbox is documented extensively, but I didn't see a > comprehensive list of the transcoding functions that a backend should > implement, nor details of these functions' inputs, nor recommendations for > handling elements that aren't obvious (tags, links, footnotes...). In my > first attempt, I even left out ox-*-template -- I had no idea what the > template was or its importance! (It is actually sort of covered on worg, > but it's buried in a quoted docstring with nothing to highlight its rather > crucial nature.) > > I've had to infer these from ox-ascii.el, which also covers a lot of cases > that aren't relevant to this exporter, making it hard to guess what is > strictly necessary. The result for me has been rather remarkable amounts of > wasted time. I know what you feel. I'm about two thirds into ox-latex;-). I don't treat it exactly like I wasted that time. I hear that reading other people's code is a good way to learn. (It was also not /that/ time-consuming, either; studying ox-latex has taken me less than 5 hours so far over the course of about three weeks (I had some breaks). Hooray for clocking;-)!) > I also wonder about documenting functions without documenting their > arguments. Like, yesterday I was trying to use org-export-get-parent: > first, find out that the function exists on worg, then switch to emacs and > C-h f it to find out *really* how to use it. Why C-h f? Because the worg > page says *nothing* about the arguments! > > At the very least, another section needs to be added, listing the elements > that need to be transcoded. Also some common cases might be nice, e.g., > what's the canonical way to access tags? Properties? Typical cases for > links that you wouldn't think of unless you already know what you're doing > (but if you already knew what you're doing, you wouldn't be scouring the > reference)? > > I'll add that, despite some painful false starts, I've got a shocking > amount of the elements working already. Some, that I might have expected to > be hard (e.g., plain lists) were close to trivially easy! So I'd say the > exporter design is a thing of beauty -- serious applause for this -- it's > just that the entry point involves too much puzzling over source code and > not enough well-organized explanation. Again, I know what you feel. Writing a custom exporter is in fact easier than one might think. I'd love to see a tutorial for writing custom exporters. (I did write one such exporter, a modification of the HTML one: https://github.com/mbork/org-edu-html . I'm planning to write at least two more.) I might start such a tutorial, but I don't feel competent enough to make it comprehensive. Also, I'm not sure whether I'll be able to handle this spare-time-wise. But I'll think about it and I'll try to try that (no mistake here). What I find especially missing is: documenting the underlying data structures (and overall architecture – in fact, I was thinking today about writing a blog post about the main entry points to the exporter, but this will probably have to wait a week or two), and a way to debug it. While generating a data structure for an element is easy (org-element-at-point), the `info' parameter is rather mysterious for me (yet). I guess I'll have to run a few exporter functions through edebug or something... [After a while, thinking.] OK, to be more constructive: I think I will be able to reserve some time for studying for and writing such a tutorial. What form would be reasonable? Is a github repo with an org file a good idea? I guess that when (or rather `if'?) it gets in a reasonable shape, transferring it to worg might be useful, but this might not happen to soon. > hjh Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Zotero csl file that uses parenthetical style for citations
On Friday 06 March 2015 06:57 PM, Rasmus wrote: > Vaidheeswaran C writes: > >> I am trying to locate a Zotero csl file that produces parenthetical >> style -- Author (Date) -- for citations[1]. The primer[2] uses the >> term "in-text" to refer to what this mailing list has been designating >> as "parenthetical" style. > > Author-date a la biblatex have two primary calls: \texcite, e.g. A () > and \parencite, e.g. (A ). You can also cite just the author or just > the year. > Based on this¹ discussion, I'm not sure CSL supports both within a single > style file. Perhaps several CSL files could be combined to support this > workflow, e.g. via citeproc-java's command line program. The point is such a CSL file should exist apriori. I am just asking the participants to produce such a CSL file. >> I want to see an "off-the-shelf" csl style file, that uses >> parenthetical style. Can someone else produce this CSL file? > Maybe this: > > > https://github.com/citation-style-language/styles/blob/master/chicago-author-date.csl I have looked at this style file and I have even written a CSL macro for this file. Please tell me how would I create parenthetical styles with this CSL file. > ¹ http://citationstyles.org/styles/, section "Suppress Author" The page says: Suppress Author With “author” and “author-date” styles, you might want to write “as discussed by Doe (2002), … ” instead of “as previously discussed (Doe, 2002)”. While CSL styles only define complete citations, e.g. “(Doe, 2002)”, the word processor plugins of Zotero, Mendeley, and Papers all allow you to suppress the author(s) in individual citations, which would leave you with just “(2002)”. You then have to write the author’s name by hand. The question now is: Who types the author name. The style file suppresses the author and it would mean the document author types it, right? So what toolchain are we looking at. How good we know these toolchains to actually integrate Org-mode with it?
Re: [O] Zotero csl file that uses parenthetical style for citations
On Friday 06 March 2015 06:59 PM, Rasmus wrote: > Vaidheeswaran C writes: > >> I am approaching this whole thread from a "tools" perspective. > > https://www.ctan.org/pkg/biblatex > http://www.ctan.org/pkg/biblatex-chicago > http://www.ctan.org/pkg/biblatex-apa > http://www.ctan.org/pkg/natbib > http://www.ctan.org/pkg/chicago > http://www.ctan.org/pkg/harvard > Does biblatex integrate with CSL engine? I sense a lot of enthusiasm to use CSL styles. If biblatex works with CSL it would be wonderful.
Re: [O] Zotero csl file that uses parenthetical style for citations
On Friday 06 March 2015 06:59 PM, Rasmus wrote: > Vaidheeswaran C writes: > >> I am approaching this whole thread from a "tools" perspective. > > https://www.ctan.org/pkg/biblatex > http://www.ctan.org/pkg/biblatex-chicago > http://www.ctan.org/pkg/biblatex-apa > http://www.ctan.org/pkg/natbib > http://www.ctan.org/pkg/chicago > http://www.ctan.org/pkg/harvard > Does biblatex integrate with CSL engine? I sense a lot of enthusiasm to use CSL styles. If biblatex works with CLS it would be wonderful.
Re: [O] Zotero csl file that uses parenthetical style for citations
Hi, Vaidheeswaran C writes: >> Maybe this: >> >> >> https://github.com/citation-style-language/styles/blob/master/chicago-author-date.csl > > I have looked at this style file and I have even written a CSL macro > for this file. Please tell me how would I create parenthetical styles > with this CSL file. I haven't tested this as I'm using bibtex for my own work. But with citeproc-java you should be able to do something like: citeproc-java -b references.bib -s chicago-author-date -c Fowler_2010 Kisker_2012 To get something like (Fowler 2010; Kisker 2012). > The question now is: Who types the author name. The style file > suppresses the author and it would mean the document author types it, > right? My interpretation of the text is "if you want 'A (Y)' I will type '(Y)' but you will have to type 'A' — manually(!)". However, if you could combine styles you could just switch the '-s' argument when calling citeproc-java (or a compatible tool). > So what toolchain are we looking at. How good we know these > toolchains to actually integrate Org-mode with it? Last resort you could import all references as org-bibtex entries and use some tool to format information from this. It's much nicer to rely on an external tool for this, though. —Rasmus -- Me gusta la noche, me gustas tú
Re: [O] Zotero csl file that uses parenthetical style for citations
Vaidheeswaran C writes: > Does biblatex integrate with CSL engine? I don't think so. > I sense a lot of enthusiasm to use CSL styles. It has good support outside of LaTeX, e.g. Mendely and Zotero. I'm not sure Bibtex is easily supported on these formats, maybe 'cause it's a postprocessor, though e.g. tex4ht manages to produce citation in xml-like documents. I believe latexml also has some support for bibtex in xml-like documents. I don't know much about these cases. —Rasmus -- . . . The proofs are technical in nature and provides no real understanding
Re: [O] Zotero csl file that uses parenthetical style for citations
I got the subject and also text wrong. (But I hope my intention was clear.) I am really looking for EXISTING in-text CSL styles. On Friday 06 March 2015 07:27 PM, Rasmus wrote: > Hi, > > Vaidheeswaran C writes: > > >>> Maybe this: >>> >>> >>> https://github.com/citation-style-language/styles/blob/master/chicago-author-date.csl >> >> I have looked at this style file and I have even written a CSL macro >> for this file. Please tell me how would I create parenthetical styles >> with this CSL file. > > I haven't tested this as I'm using bibtex for my own work. But with > citeproc-java you should be able to do something like: > > citeproc-java -b references.bib -s chicago-author-date -c Fowler_2010 > Kisker_2012 > > To get something like (Fowler 2010; Kisker 2012). > >> The question now is: Who types the author name. The style file >> suppresses the author and it would mean the document author types it, >> right? > > My interpretation of the text is "if you want 'A (Y)' I will type '(Y)' > but you will have to type 'A' — manually(!)". > > However, if you could combine styles you could just switch the '-s' argument > when calling citeproc-java (or a compatible tool). > >> So what toolchain are we looking at. How good we know these >> toolchains to actually integrate Org-mode with it? > > Last resort you could import all references as org-bibtex entries and use > some tool to format information from this. It's much nicer to rely on an > external tool for this, though. > > —Rasmus >
Re: [O] Zotero csl file that uses parenthetical style for citations
I think the post-processor type tool is what would give the most capabilities. The citations produced depends on the context. (For example, is it a second refernce to an earlier occurrence etc. Is this an "Ibid" stuff etc.) JabRef and Citeproc-java cannot do that. My suggestion, people take A tool and evaluate it in terms of a feature matrix. On Friday 06 March 2015 08:25 PM, Rasmus wrote: > Vaidheeswaran C writes: > >> Does biblatex integrate with CSL engine? > > I don't think so. > >> I sense a lot of enthusiasm to use CSL styles. > > It has good support outside of LaTeX, e.g. Mendely and Zotero. > > I'm not sure Bibtex is easily supported on these formats, maybe 'cause > it's a postprocessor, though e.g. tex4ht manages to produce citation in > xml-like documents. I believe latexml also has some support for bibtex in > xml-like documents. I don't know much about these cases. > > —Rasmus >
Re: [O] Zotero csl file that uses parenthetical style for citations
On Friday 06 March 2015 07:27 PM, Rasmus wrote: > Last resort you could import all references as org-bibtex entries and use > some tool to format information from this. It's much nicer to rely on an > external tool for this, though. We are talking about 100 options -- JabRef, Citeproc-java, org-bibtex, biblatex -- all at the same time. Is it really difficult to fix one toolset and knock that option once and for all. Too many options will lead only to confusion and a delayed progress.
[O] Small bug? org-narrow-to-subtree and open file link
Hi, maybe this is a small bug or something wrong in my config... But: if I use org-narrow-to-subtree and then use org-return to open a file link the narrowed function get lost and I get the whole buffer again. This happens at least if I get a question because the file is too big and I have to decide whether I want to open it (this by the way divides the window very unexpectedly...). I'm using Org-mode version 8.2.10. Any hint? Many thanks in advance!
Re: [O] What to use for tables with lengthy text in cells?
One more crazy idea. What if there were a choice of two vertical separators? Currently '|' is the only character used for this purpose. If, however, something like '\' were used to signal a multi-line cell, then it would be possible to control this feature on a row-by-row basis. As soon as the user replaces one of the '|' characters with '\', all vertical separators in that row also change, converting all of its cells to multi-line text. This has the advantage of being backward compatible and not overloading the horizontal line separator.
Re: [O] What to use for tables with lengthy text in cells?
I think \ is overloaded for export purposes, but maybe / is clear? I think that's a good idea. Skip Collins writes: > One more crazy idea. What if there were a choice of two vertical > separators? Currently '|' is the only character used for this purpose. > If, however, something like '\' were used to signal a multi-line cell, > then it would be possible to control this feature on a row-by-row > basis. As soon as the user replaces one of the '|' characters with > '\', all vertical separators in that row also change, converting all > of its cells to multi-line text. This has the advantage of being > backward compatible and not overloading the horizontal line separator.
Re: [O] Small bug? org-narrow-to-subtree and open file link
Igor Sosa Mayor gmail.com> writes: > > Hi, > > maybe this is a small bug or something wrong in my config... > > But: if I use org-narrow-to-subtree and then use org-return to open a > file link the narrowed function get lost and I get the whole buffer > again. This happens at least if I get a question because the file is too > big and I have to decide whether I want to open it (this by the way > divides the window very unexpectedly...). > > I'm using Org-mode version 8.2.10. > > Any hint? > > Many thanks in advance! > > Igor, org-narrow-to-subtree creates a subtree buffer. Your org-return call within that new subtree buffer command operates on the base buffer. Many of Org's link navigation commands operate this way because they use the base buffer as their context.
Re: [O] Comment on Org Export Reference
Marcin Borkowski writes:
> What I find especially missing is: documenting the underlying data
> structures (and overall architecture – in fact, I was thinking today
> about writing a blog post about the main entry points to the exporter,
> but this will probably have to wait a week or two), and a way to debug
> it. While generating a data structure for an element is easy
> (org-element-at-point), the `info' parameter is rather mysterious for me
> (yet). I guess I'll have to run a few exporter functions through edebug
> or something...
`info' contents are almost completely explained in the reference
documentation ("The Communication Channel" section). Missing properties
are those used as a cache in various functions
(e.g. :resolve-fuzzy-link-cache for `org-export-resolve-fuzzy-link').
Regards,
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Rasmus writes: > This is also not captured: [cite:@Röntgen]. Why limit > org-element--citation-key-re to a-z? Done in 8c941008e0aaf958bdc6ae2cc7dfcbe3fd967b92. While we're at it, as you noticed already, bare citation keys take precedence over subscript. So, basically, one can never add subscript to a word starting with "@". At the bare minimum, we should introduce an entity to generate "@" (e.g. "\At") so one can always write \At_2 WDYT? Regards,
Re: [O] What to use for tables with lengthy text in cells?
It might even be desirable to mix single and multi line cells in the same row. That would introduce some restrictions on how single-line cells are edited when they are in a row that contains multi-line cells. I suppose they could be collapsed onto the first line in the cell by replacing newlines with spaces. That would also have to be handled carefully when converting a multi-line cell back to single line. On Fri, Mar 6, 2015 at 11:48 AM, Tory S. Anderson wrote: > I think \ is overloaded for export purposes, but maybe / is clear? I think > that's a good idea. > > Skip Collins writes: > >> One more crazy idea. What if there were a choice of two vertical >> separators? Currently '|' is the only character used for this purpose. >> If, however, something like '\' were used to signal a multi-line cell, >> then it would be possible to control this feature on a row-by-row >> basis. As soon as the user replaces one of the '|' characters with >> '\', all vertical separators in that row also change, converting all >> of its cells to multi-line text. This has the advantage of being >> backward compatible and not overloading the horizontal line separator.
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Nicolas Goaziou writes: > While we're at it, as you noticed already, bare citation keys take > precedence over subscript. So, basically, one can never add subscript to > a word starting with "@". > > At the bare minimum, we should introduce an entity to generate "@" > (e.g. "\At") so one can always write > > \At_2 > > WDYT? My gut feeling tells me that scripts are "more important" than citations. [To me this is certainty not true, I always use subscripts inside latex fragments/envs]. But I can't think of anything better than your suggestion and I think it's acceptable. —Rasmus -- With monopolies the cake is a lie!
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
Hi Vaidheeswaran,
Vaidheeswaran C writes:
> The following combination works when passed through the LaTeX/PDF
> exporter. It doesn't work when the cite syntax is switched to the new
> one.
>
> \cite{center_for_history_and_new_media_zotero_}
Is that a realistic example of a key? What program is generating it?
JabRef?
I am not too worried about this case. I am guessing that the four "?"s
at the end are inserted because the generating program wasn't sure how
to encode some characters. I think the right thing to do in edge cases
like this is instruct the user that the key is invalid (at least from
Org's perspective) and they should change it. If key-ending punctuation
turns out to be common, I would revise this opinion, but at the moment I
don't see the need.
I do not think we should allow punctuation at the end of keys, because
that will make it too hard to write in-text citations at the end of a
clause, like: "For more, see @Doe99." or "Can we replicate the results
of @Doe99?" or "The following cases have been documented in @Doe99: ..."
Best,
Richard
[O] Error with Org Export
I'm trying to export to HTML a file with this snippet of text:
<<
call_function 0; store 1 (a)
>>
Doing so gives me the error: *Variable "store" must be assigned a default
value*
This goes away if I remove the underscore. I've tried using #+OPTIONS: ^:{}
to address this, but it doesn't have any effect, nor does #+OPTIONS: ^:nil
Org is version 8.2.10. Emacs is 25.0.50.1.
What seems to be the matter here and how can I fix it?
Re: [O] Zotero csl file that uses parenthetical style for citations
Hi Vaidheeswaran, Vaidheeswaran C writes: > I got the subject and also text wrong. (But I hope my intention was > clear.) I am really looking for EXISTING in-text CSL styles. Rasmus pointed you to a relevant style: https://github.com/citation-style-language/styles/blob/master/chicago-author-date.csl I think you might be mixing up two different distinctions. A "parenthetical style" like this one is distinguished from, say, a numeric style (like the ACM styles, I think). This distinction between "parenthetical" and numeric styles applies to the document as a whole. This distinction is orthogonal to the distinction between whether *individual citations* are parenthetical (like "(Auth 2000)") or in-text (like "Auth (2000)"). So there is not really any such thing as an "in-text CSL style". Rather, there are CSL styles that support both in-text and parenthetical citations (which is most of them, I'd guess). Best, Richard
[O] Plotting in Python block won't over-write existing file
Here’s a sample Python code block:
#+begin_src python :results file :exports both
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
import pandas as pd
df = pd.DataFrame({'date': [1900, 1901, 1902], 'x1' : [3, 4, 5], 'x2' : [6, 7,
9]})
df.set_index('date', inplace=True, drop=True)
df.plot()
plt.savefig('x4.png')
return 'x4.png' # return filename to org-mode
#+End_src
When I run it, the graph appears on the screen and in the named file, as
desired.
However, if I go back, change one of the numbers, and rerun the block, while it
claims to have run OK, the graph is not updated. I only get a new plot if I
also change the file name (e.g., to x5.png). It looks like it’s refusing to
over-write an existing file. Is there a reason for this, and is there a way to
change this behavior?
By the way, this is with org-mode 8.3beta-884-g9ed426
Thanks.
Richard Stanton
Re: [O] Small bug? org-narrow-to-subtree and open file link
James K. Lin writes: > org-narrow-to-subtree creates a subtree buffer. Your org-return call within > that new subtree buffer command operates on the base buffer. Many of Org's > link navigation commands operate this way because they use the base buffer > as their context. thanks for your answer... I did not know about this... there is also little to do?
Re: [O] Error with Org Export
Chris Drane writes:
> I'm trying to export to HTML a file with this snippet of text:
>
> <<
> call_function 0; store 1 (a)
>>>
>
> Doing so gives me the error: Variable "store" must be assigned a default value
>
> This goes away if I remove the underscore. I've tried using #+OPTIONS: ^:{}
> to address this, but it doesn't have any effect, nor does #+OPTIONS: ^:nil
>
> Org is version 8.2.10. Emacs is 25.0.50.1.
>
> What seems to be the matter here and how can I fix it?
I guess it thinks it's an inline babel call.
If it's just text, you can use an entity:
call\under{}function 0; store 1 (a)
Nick
Re: [O] Plotting in Python block won't over-write existing file
Richard Stanton writes:
> Here’s a sample Python code block:
>
> #+begin_src python :results file :exports both
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as plt
> import pandas as pd
>
> df = pd.DataFrame({'date': [1900, 1901, 1902], 'x1' : [3, 4, 5], 'x2' : [6,
> 7, 9]})
> df.set_index('date', inplace=True, drop=True)
> df.plot()
> plt.savefig('x4.png')
> return 'x4.png' # return filename to org-mode
> #+End_src
>
> When I run it, the graph appears on the screen and in the named file, as
> desired.
>
> However, if I go back, change one of the numbers, and rerun the block,
> while it claims to have run OK, the graph is not updated. I only get a
> new plot if I also change the file name (e.g., to x5.png). It looks
> like it’s refusing to over-write an existing file. Is there a reason
> for this, and is there a way to change this behavior?
>
> By the way, this is with org-mode 8.3beta-884-g9ed426
>
IIUC, you eval the code, hit the resulting link (which opens a buffer with the
graph), change a number and reeval the code - do you hit the link again?
That should ask you whether you want to read the changed file again and
show the updated graph.
Nick
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
On Friday, 6 Mar 2015 at 18:55, Rasmus wrote: > My gut feeling tells me that scripts are "more important" than citations. My gut agrees with yours on this. However, the precedence for citations is only for words starting with @ so this should not pose a problem generally. I cannot remember ever using @ in normal prose... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-843-ga5f1a3.dirty
Re: [O] Small bug? org-narrow-to-subtree and open file link
Igor Sosa Mayor gmail.com> writes: > > James K. Lin yahoo.com> writes: > > > org-narrow-to-subtree creates a subtree buffer. Your org-return call within > > that new subtree buffer command operates on the base buffer. Many of Org's > > link navigation commands operate this way because they use the base buffer > > as their context. > > thanks for your answer... I did not know about this... there is also > little to do? > > By default, Org mode does not work well with indirect buffers. You could get around this by rolling your own version of functions on your own to ignore the base buffer. This is no small feat because the link navigation commands are nested.
Re: [O] [ox-ascii, bug?] aligning text withing footnotes
Hello, Rasmus writes: > When writing plain text I might write something like: > > See foo[fn:1] > > [fn:1] http://orgmode.org/\\ >http://www.gnu.org/software/emacs/ > > This is exported as: > > See foo[1] > > Footnotes > ─ > > [1] [http://orgmode.org/] >[http://www.gnu.org/software/emacs/] This should be fixed. Expected indentation is: [1] [http://orgmode.org/] [http://www.gnu.org/software/emacs/] > I would like to have the links aligned after the ascii export. That is, > if line 1 of a footnote is "shifted" n characters to the left, I would > like all subsequent lines of that element to be shirted n characters to > the left. You mean this this indentation scheme for footnotes [1] Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enimad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. instead of [1] Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enimad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. > But maybe this would have other bad effects? It looks like plain lists. Anyway I don't have strong opinion about it. Regards, -- Nicolas Goaziou
Re: [O] Comment on Org Export Reference
On March 6, 2015 7:21:50 PM Nicolas Goaziou wrote: James Harkins writes: > The page covers a lot of details, but less in the way of context. For > instance, the toolbox is documented extensively, but I didn't see > a comprehensive list of the transcoding functions that a backend > should implement There is no rule about what a back-end should implement (besides template). Should, or could. Anyway full list of supported elements and objects, along with all associated properties is in "Org Element API" document[fn:1]. Ah, OK! The connection between these and the exporter was, for whatever reason, not obvious to me. (I may perhaps be forgiven for this: a search of the export reference for "API" yielded no results.) Maybe all the document needs is to call attention to the relationship and give a few examples. *That* is something I can handle. A full tutorial is more time than I can afford now, but might not be needed after all. hjh Sent with AquaMail for Android http://www.aqua-mail.com
[O] Setting `org-src-window-setup` has no effect? [was: Re: Bug: `org-edit-special` doesn't respect dedicated windows]
Ping? On 2015-03-01T20:31:33+1100, Alexis said: A> On 2015-03-01T20:20:06+1100, Nicolas Goaziou said: NG> Org uses `org-src-window-setup' to control the display, which NG> overrides dedicated windows. You may want to customize the A> former. A> Thanks for bringing my attention to this variable! However, A> setting it to 'current-window seems to have no effect; rather than A> the Org buffer being replaced by an Emacs Lisp buffer, either a A> new window is created for the latter, or an existing A> (non-dedicated) window is taken over by the latter. Am i missing A> something / doing something else wrong? A> (Btw, i'm using version 20150223 of Org from the orgmode.org ELPA A> - sorry i didn't mention that in my previous message!) A> Alexis.
Re: [O] Citation syntax: Underscore MUST(?) be allowed in cite keys?
On Friday 06 March 2015 11:39 PM, Richard Lawrence wrote:
> Hi Vaidheeswaran,
>
> Vaidheeswaran C writes:
>
>> The following combination works when passed through the LaTeX/PDF
>> exporter. It doesn't work when the cite syntax is switched to the new
>> one.
>>
>> \cite{center_for_history_and_new_media_zotero_}
>
> Is that a realistic example of a key?
Yes.
> What program is generating it? JabRef?
It is generated by Zotero.
> I am not too worried about this case.
Have you tried it with \cite{} and \bibliography{} combination and
seen it works or not. My argument relies on how existing tool works.
> I am guessing that the four "?"s at the end are inserted because the
> generating program wasn't sure how to encode some characters.
I see that you haven't exporter Zotero libraries to .bib files. My
guess is the 4 question marks are for "missing" (or "irrelevant")
digits.
> If key-ending punctuation turns out to be common, I would revise
> this opinion, but at the moment I don't see the need.
I am not imagining things. I am pointing out how existing tools
behave.
Re: [O] Status of MobileOrg for iOS?
David Masterson writes: > What is the status of MobileOrg for iOS? It seems stalled but, AFAIK, it is free software and higly hackable if you have the knowledge and time ^^ As I did not have either resource, I decided to stop using MobileOrg ;) After all, I did not use it much and I had problems with the UX. Regards -- Xavier.
Re: [O] Bug: org-habit treats all repeat tasks as ".+" type [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)]
Thanks for your help, Nicolas and kungdash. I've tried both 8.2.10 (installing via elpa) and the git repository (8.3-beta and master branches), but still the same. I also tried with putting those DONE logs after the properties, but nothing change. On 6 March 2015 at 19:05, Nicolas Goaziou wrote: > Hello, > > 何利勇 writes: > > > It looks like org-habit only handle the ".+" repeater correctly, though > > the document says it supports ".+", "++" and "+". > > > > For example, when create agenda for the following org content. > > > > * TODO Test_+ > > SCHEDULED: <2015-03-02 Mon +1w> > > - State "DONE" from "TODO" [2015-02-23 Mon 10:56] > > - State "DONE" from "TODO" [2015-02-16 Mon 10:56] > > - State "DONE" from "TODO" [2015-02-10 Tue 10:56] > > - State "DONE" from "READY" [2015-02-02 Mon 10:56] > > :PROPERTIES: > > :STYLE:habit > > :LAST_REPEAT: [2015-02-23 Mon 10:56] > > :ID: e960c39e-4f92-4ef0-a5ee-a4d3fcfd26bf > > :END: > > > > * TODO Test_++ > > SCHEDULED: <2015-03-02 Mon ++1w> > > - State "DONE" from "TODO" [2015-02-23 Mon 10:56] > > - State "DONE" from "TODO" [2015-02-15 Sun 10:56] > > - State "DONE" from "READY" [2015-02-02 Mon 10:56] > > :PROPERTIES: > > :STYLE:habit > > :LAST_REPEAT: [2015-02-23 Mon 10:56] > > :END: > > I don't think this bug still exists in a recent Org. Could you update > Org (preferably to development version) and test it again? > > Note that in development version, entries above are somewhat invalid > because properties drawer must be located just after "SCHEDULED" line. > > Thank you. > > > Regards, > > -- > Nicolas Goaziou >
Re: [O] [ANN] org-dp-wrap-in-block
H Thorsten
i know this is a *very* late response but life/work has dragged me in last
few months and only now i have time to take a look at org-dp :)
if you remember i have near to null coding skills but i am trying to make
sense of stuff looking at the github site and the org-dp.el examples
i understand (or at least i think i do) that org-dp is very complex and
covers not just wrapping in source code lines/areas but what i basically
need is to assign hotkeys to specific wrapping. mainly these:
1. a hotkey to quick wrap in language X a line
2. a hotkey to quick wrap in language X y lines
3. a hotkey to quick wrap in language X a selection
any tips and how to start/create these keybinds? is there a more
comprehensive documentation on org-dp somewhere else i may have overlooked?
thx alot!
z
On Tue, Aug 19, 2014 at 10:41 PM, Thorsten Jolitz wrote:
> Xebar Saram writes:
>
> Hi,
>
> > will use it over the next few days and report bug (if any) that i find
>
> good, thanks.
>
> As a hint, here the global keybindings I defined in my init.el (my
> default use-case is to simply wrap in a plain emacs-lisp src-block).
>
> You can define all kinds of functions that don't prompt the user anymore
> by giving a list like
>
> '(elem-type contents replace affiliated args)
>
> as second arg to `org-dp-wrap-in-block', and in that list you can
> specify any kind of customized block.
>
> #+BEGIN_SRC emacs-lisp
> (when (require 'org-dp-lib nil t)
>
> (defun tj/wrap-in-elisp-block ()
> (org-dp-wrap-in-block
> nil '(src-block nil nil nil (:language "emacs-lisp"
>
> (global-set-key (kbd "C-c w w") 'org-dp-wrap-in-block)
>
> (global-set-key (kbd "C-c w l")
> (lambda ()
> (interactive)
> (let ((current-prefix-arg '(4)))
> (call-interactively
>'org-dp-wrap-in-block
>
> (global-set-key (kbd "C-c w e")
> (lambda ()
> (interactive)
> (beginning-of-line)
> (tj/wrap-in-elisp-block)))
>
> (global-set-key (kbd "C-c w a")
> (lambda ()
> (interactive)
> (backward-sexp)
> (beginning-of-line)
> (tj/wrap-in-elisp-block))) )
> #+END_SRC
>
>
> > On Tue, Aug 19, 2014 at 5:14 PM, Thorsten Jolitz
> > wrote:
> >
> > Hi List,
> >
> > I've written the "eierlegende Wollmilchsau" of wrap-in-block
> > functions
> > (i.e. the 'all-inclusive mother of all wrap-in-block functions').
> >
> > To check it out, you need to
> > 1. Clone or fork the git repo (https://github.com/tj64/org-dp)
> > 2. (add-to-list 'load-path "/path/to/org-dp/") and
> > 3. (require 'org-dp-lib') in your init file
> >
> > `org-dp-wrap-in-block' works on/with all kinds of Org blocks, and
> > can be
> > called interactively or non-interactively.
> >
> > It
> >
> > - inserts a new block when called on an empty line without
> > arguments
> >
> > - wraps sexp or region or '+/- X lines from point' into a newly
> > created
> > block
> >
> > - when called with point inside a block, it either
> >
> > + unwraps the blocks content, i.e. deletes the surrounding block
> > or
> >
> > + replaces the surrounding block with a different block
> >
> > It takes full account of affiliated keywords. In case of
> > src-blocks,
> > it puts src-block parameters on the block's headline, but with
> > `org-dp-toggle-headers' its easy to toggle between parameters
> >
> > ,
> > | #+begin_src R :noweb yes
> > `
> >
> > and headers
> >
> > ,
> > | #+header: :noweb yes
> > | #+begin_src R
> > `
> >
> > This function takes into account so many options that
> > combinatorics hits
> > you badly when trying to test all of them. Everything I tried
> > works now
> > with the current version, but its not unlikely that daily usage
> > will
> > discover some bugs or untreated corner cases. Please report them
> > with
> > backtrace.
> >
> > The good news is that besides its complexity, its not one
> > mega-convoluted monolithic function for a single task only.
> > Instead I
> > outfactored the core functionality into the 'org-dp.el' library
> > ("Declarative Programming with Org Elements") which offers
> > potentially
> > massive time (and headache) savings when programming with Org
> > Elements
> > on the local level.
> >
> > 'org-dp' acts on the internal representation of Org elements, and
> > due to
> > the total uniformity of this representation it is possible to do
> > diverse
> > actions on diverse elements in a very uniform way, thus the 3
> > functions
> >
> > - `org-dp-create'
> >
> > - `org-dp-rewire'
> >
> > - `org-dp-prompt'
> >
> > should be all
Re: [O] Zotero csl file that uses parenthetical style for citations
On Friday 06 March 2015 11:51 PM, Richard Lawrence wrote: > Hi Vaidheeswaran, > > Vaidheeswaran C writes: > >> I got the subject and also text wrong. (But I hope my intention was >> clear.) I am really looking for EXISTING in-text CSL styles. > > Rasmus pointed you to a relevant style: > > https://github.com/citation-style-language/styles/blob/master/chicago-author-date.csl > > I think you might be mixing up two different distinctions. A > "parenthetical style" like this one is distinguished from, say, a > numeric style (like the ACM styles, I think). This distinction between > "parenthetical" and numeric styles applies to the document as a whole. > > This distinction is orthogonal to the distinction between whether > *individual citations* are parenthetical (like "(Auth 2000)") or in-text > (like "Auth (2000)"). > > So there is not really any such thing as an "in-text CSL style". > Rather, there are CSL styles that support both in-text and parenthetical > citations (which is most of them, I'd guess). Your guess is just a guess. You haven't looked at chicago-author-date style, have you? You can prove yourself right by (a) producing an "off-the-shelf" CSL file that uses BOTH "in-text" AND "parenthetical" citations. (b) producing a csl-based tool that ORG CAN INTERFACE WITH that produces "in-text" AND "parenthetical" styles.
Re: [O] Status of MobileOrg for iOS?
Xavier Maillard writes: > David Masterson writes: > >> What is the status of MobileOrg for iOS? > > It seems stalled but, AFAIK, it is free software and higly hackable > if you have the knowledge and time ^^ > > As I did not have either resource, I decided to stop using MobileOrg > ;) After all, I did not use it much and I had problems with the UX. It does seem somewhat stalled, but it does seem to work once you get it set up. I hope I can find time to work on it in the future. It could use the following: 1. Further details in the documentation. 2. A better description of what MobileOrg can and cannot do. 3. Simpler data entry/update methods (perhaps Siri?). 4. Exchange between iPhone outliners and MobileOrg. Overall, for managing your life, I see very little better than Org especially if you are used to working with Emacs. And Org is free and always improving (as is obvious from this newsgroup). The one issue that has been holding me back was accessing and updating my tasks and overall "life outlines" from my iPhone which is always with me. MobileOrg begins to address that, but I have a lot to learn on using both. -- David Masterson Programmer At Large
Re: [O] Status of MobileOrg for iOS?
Hi David, David Masterson writes: > Xavier Maillard writes: > >> David Masterson writes: >> >>> What is the status of MobileOrg for iOS? >> >> It seems stalled but, AFAIK, it is free software and higly hackable >> if you have the knowledge and time ^^ > > It does seem somewhat stalled, but it does seem to work once you get it > set up. I hope I can find time to work on it in the future. It could > use the following: > > 3. Simpler data entry/update methods (perhaps Siri?). Oh YEAH ! :D > Overall, for managing your life, I see very little better than Org > especially if you are used to working with Emacs. I can't agree more with that ! I wish I had an EmacsOS smartphone ^^. > The one issue that has been holding me back was accessing and >updating my tasks and overall "life outlines" from my iPhone which >is always with me. MobileOrg begins to address that, but I have a >lot to learn on using both. I hardly edit my lists directly onto my smartphone. I find it quite complicated and error prone but my main UX problem is with tha ability to export an encrypted version of my orgfiles. I do not want them to be stored as clear text on something like Dropbox. Until I can GPG encrypt them and make mobileorg using it that way, I won't use it again ^^ (That means MobileOrg can deal with GPG encrypted files too.). Regards -- Xavier.
Re: [O] Zotero csl file that uses parenthetical style for citations
On Friday 06 March 2015 07:27 PM, Rasmus wrote: > My interpretation of the text is "if you want 'A (Y)' I will type '(Y)' > but you will have to type 'A' — manually(!)". The details like these are important from design stand of view. Do people who are lobbying for integration with CSL tools paying attention to these details and ferreting out these in front of this forum.
