Re: [O] [patch] better(?) indention for cdlatex-environment
Rasmus writes: > It's a very good idea! On the top of my head there's two issues. > > 1. cdlatex-environment doesn't work with buffers, only files...¹ I think > it doesn't even work with (with-temp-file · ⋯) without saving the file > first. Try: > > (require 'cdlatex) > (require 'reftex) > (with-temp-buffer (cdlatex-environment "equation")) > > 2. if run from a temporary buffer, the refcounter would always be one. > Perhaps there would be a way to update it afterwards. I see. Another idea: (let ((beg (point-marker)) (end (copy-marker (point) t))) (cdlatex-environment "equation") (prog1 (delete-and-extract-region beg end) (set-marker beg nil) (set-marker end nil))) If it is not the empty string, indent it and insert it again... Regards,
Re: [O] ox and links to equation
Rasmus writes:
> I have two issues with linking to equations.
>
> Consider the following example:
>
> \begin{alinged}
> \Label{eq:1}
> \min f(x)\\
> \label{eq:2}
> \st c(x)=0
> \end{aligned}
> Insightful comments on [[eq:1]] and [[eq:2]]
>
>
> * Issue 1
>
> If org-link-search-must-match-exact-headline is nil the links will work in
> the buffer. However, they will be discarded on export. Eq:1 I can refer
> to if I give the latex-environment a #+NAME, but I can't refer to eq:2. I
> think it should be possible to put in a link for eq:2. I don't know if it
> should depend on org-link-search-must-match-exact-headline or not,
> probably not.
>
> Any ideas how this could be solved and whether it's desirable solving?
`org-link-search-must-match-exact-headline' is ignored during export.
Since there are other ways to point to a particular location in
a document, it is an acceptable limitation.
For the problem at hand, you can use \label{eq:2} directly in the
document.
> * Issue 2 (ox-latex specific)
>
> Since we now have amsmath in the org-default-package-alist I would like to
> \eqref{·} to refer to equations. The main difference is that it takes
> care of the parenthesis automatically. I.e. \ref{eq:2} → 2 and
> \eqref(eq:2) → (2). Also, mathtools works with \eqref, but not \ref.
> However, in old document it could lead to ((2)).
>
> I have a simple patch that hard-coded equation to \eqref, but I don't know
> if a more general approach should be taken. Or if it a filter issue.
I'm not sure \eqref is desirable as a default value, (but I don't oppose
it if you think it is). OTOH, a filter is easy enough to implement.
Regards,
[O] Why not push?
Hi there, 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? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Why not push?
Hello, Marcin Borkowski writes: > 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? No. Good luck with refactoring "org.el". ;) Regards, -- Nicolas Goaziou
Re: [O] Why not push?
Nicolas Goaziou writes: > Hello, > > Marcin Borkowski writes: > >> 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? > > No. Good luck with refactoring "org.el". ;) Shhh... if you don't say anything, he might go and do it!
Re: [O] [patch, ox-latex] better hyperref and title options
Hello, Rasmus writes: > Nicolas Goaziou writes: > >>> +(?k . ,(or (plist-get info :keywords) "")) >>> +(?d . ,(or (plist-get info :description) "")) > > So it occurred to me that these should also be exported to proper syntax > so we don't end up with e.g. a raw $ or & in our latex document. Hyperref > will actually handle it, but usually by discarding offending characters. > > However, since they are plain strings something like \alpha will be > exported as $\backslash$lpha. I can kind of get it interpreting using > org-element-parse-secondary-string, but this is not the right > approach. Why isn't it the right approach? > Is there a reason why DESCRIPTION and KEYWORDS can't have formatting? DESCRIPTION could be moved to `org-element-document-properties'. But then, we need to introduce `org-export-with-description', which implies export back-ends have to deal with it somehow (ATM "ox-ascii" ignores it). Another option is to simply remove DESCRIPTION from "ox.el" and let export back-ends in need of it to add it to their definition. However, I don't see why KEYWORDS should accept markup. I also think it should be moved to back-end definitions instead of "ox.el". Regards, -- Nicolas Goaziou
Re: [O] Why not push?
On 2015-02-15, at 11:42, Eric Abrahamsen wrote: > Nicolas Goaziou writes: > >> Hello, >> >> Marcin Borkowski writes: >> >>> 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? >> >> No. Good luck with refactoring "org.el". ;) > > Shhh... if you don't say anything, he might go and do it! ;-) Actually, not. (Though it might make a nice student project. And it would be a good idea to do it.) But I haven't signed the FSF papers. OTOH, I have a personal project where I devote some amount of time every day to read someone else's code. I started with parts of simple.el, and now the time has come for ox-latex (and its dependencies). Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Citation syntax: a revised proposal
+1 Thanks for the work substantiating the idea. Richard Lawrence writes: > 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. > > This proposal represents my attempt to formulate a syntax that is easy > to read, easy to parse, and covers all the use-cases that people > mentioned as being important. It is surely not perfect, but I learned a > lot from the previous thread, and I hope something like this will serve > the community's needs. > > The proposal is below, both inline (for easy quoting) and attached (for > easy reading). To keep it relatively short, I have mostly not explained > my reasoning for the choices I made, but I am happy to do so here if > anyone has questions. > > I welcome feedback, comments, criticisms, and objections on any point. > However, since we've already had a long discussion about this, I > respectfully request that we try to keep this thread focused. To that > end, I suggest: > > 1) If you have criticisms or objections, please try to indicate > whether you think they are `substantive' (e.g., you see a problem > that would prevent you from using this syntax, or prevent Org from > implementing it) or not (e.g., you would prefer a slightly > different but equivalent way of expressing something). > > 2) If you wish to express an opinion about the proposal without > offering further comments, let us know by just replying with +1 > (meaning you'd like to see this syntax, or something reasonably > similar to it, be adopted), 0, or -1 (meaning you'd prefer not to > see this syntax or anything similar to it adopted). > > I guess this is my Valentine to the Org community. :) Thanks for reading! > > Best, > Richard > > #+TITLE: Citation syntax, a revised proposal > #+DATE: <2015-02-14 Sat> > > #+AUTHOR: Richard Lawrence > #+EMAIL: richard.lawre...@berkeley.edu > > #+LANGUAGE: en > #+SELECT_TAGS: export > > #+EXCLUDE_TAGS: noexport > > * Citation syntax > ** Requirements > A citation is a textual reference to one or more individual works, > together with other information about those works, grouped together in > a single place. > > Within a citation, each reference to an individual work needs to be > capable of containing: > 1) a database key that references the cited work > 2) prefix / pre-note > 3) suffix / post-note > > Whole citations also need: > 4) [@4] a way of specifying whether the citation is in-text or > parenthetical > 5) a way of representing a common prefix and suffix, if the citation > is a multi-cite > 6) a way of specifying whether the citation should produce a > complete bibliography entry in-place > 7) an extensible way of specifying formatting properties to export > filters and/or specific export backends > > ** Citation definitions > *** Citation keys; bibliography references vs. complete entries > A citation key consists of a unique label preceded by a flag, which is > optionally preceded by a hyphen. > > The flag is either `@' or `&'. `@' indicates that the citation should > produce a normal reference to the bibliography entry for the cited > work (in whatever style the document uses), located elsewhere. > > The `&' flag indicates that the citation should produce a complete > bibliography entry for the cited work in the place where the citation > appears. > > The optional hyphen (`-') indicates that the author's name should be > suppressed from the rendered citation. (Note that this is only useful > in author-X citation styles; it should have no effect in numeric > styles.) > > *** Basic citations: Parenthetical vs. in-text > There are two basic types of citation: /parenthetical/ and /in-text/. > Each of these may contain references to one or more individual works. > > The difference between parenthetical and in-text citations is > expressed using parentheses around the /first/ citation key. A > parenthetical citation has such parentheses around the first citation > key; an in-text citation lacks them. (Parentheses around non-initial > keys are permitted for visual consistency and to keep the grammar > simple, but have no meaning.) > > A citation thus consists in general of a bracketed list, beginning > with `cite:', of one or more individual references, each of which: > - may contain a prefix, > - must contain a citation key, which may or may not be surrounded by `(...)' > - and may contain a suffix > Individual references are separated by semi-colons. > > There are also two special cases to make simple-but-common uses very > easy to type and read: > 1) a parenthetical citation for a single work with no prefix and > suffix may be written by just surrounding the key with brackets, > like: [@Doe99]. > 2) an in-text citation for a single work with no
Re: [O] ox and links to equation
Nicolas Goaziou writes:
> For the problem at hand, you can use \label{eq:2} directly in the
> document.
Less pretty and I can't click on it. [For me a custom link type is fine,
but every line of customization makes it harder to reproduce down the
road].
Anyway, I found out that mathjax upstream now support labeling to
equations using the latex format. Try:
In equation \eqref{eq:sample}, we find the value of an
interesting integral:
\begin{equation}
\int_0^\infty \frac{x^3}{e^x-1}\,dx = \frac{\pi^4}{15}
\label{eq:sample}
\end{equation}
#+OPTIONS: html-scripts:nil
#+HTML_HEAD: https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML";>
#+HTML_HEAD:
#+HTML_HEAD:
#+HTML_HEAD: MathJax.Hub.Config({
#+HTML_HEAD: TeX: { equationNumbers: { autoNumber: "AMS" } }
#+HTML_HEAD: });
#+HTML_HEAD:
>> * Issue 2 (ox-latex specific)
>>
>> Since we now have amsmath in the org-default-package-alist I would like to
>> \eqref{·} to refer to equations. The main difference is that it takes
>> care of the parenthesis automatically. I.e. \ref{eq:2} → 2 and
>> \eqref(eq:2) → (2). Also, mathtools works with \eqref, but not \ref.
>> However, in old document it could lead to ((2)).
b>>
>> I have a simple patch that hard-coded equation to \eqref, but I don't know
>> if a more general approach should be taken. Or if it a filter issue.
>
> I'm not sure \eqref is desirable as a default value, (but I don't oppose
> it if you think it is). OTOH, a filter is easy enough to implement.
I definitely think it is the more proper way to refer to an equation. But
it really depends on the document. E.g. mathtools also offer a set of
commands for referring to equations. I was considering an alist of
(DESTINATION-TYPE REF-CMD-WITH-DESCRIPTION REF-CMD-WITHOUT-DESCRIPTION)
But it might be an overkill, especially seeing that mathjax only supports
\ref and \eqref out of the box.
—Rasmus
--
Summon the Mothership!
Re: [O] Why not push?
Marcin Borkowski writes: > Hi there, > > 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? These days you even have split-string in subr which you can make behave like org-split-string. Oh, and there's all the cl re-implementations... I like org-some better than cl-some just cause it sounds nice when you say it (try): org (tiny pause) some. —Rasmus -- When in doubt, do it!
Re: [O] [patch, ox-latex] better hyperref and title options
Nicolas Goaziou writes: >> However, since they are plain strings something like \alpha will be >> exported as $\backslash$lpha. I can kind of get it interpreting using >> org-element-parse-secondary-string, but this is not the right >> approach. > > Why isn't it the right approach? 'Cause usually org-export-data gives you the right value automatically. Anyway, I don't mind using org-element-parse-secondary-string. >> Is there a reason why DESCRIPTION and KEYWORDS can't have formatting? > > DESCRIPTION could be moved to `org-element-document-properties'. But > then, we need to introduce `org-export-with-description', which implies > export back-ends have to deal with it somehow (ATM "ox-ascii" ignores > it). > Another option is to simply remove DESCRIPTION from "ox.el" and let > export back-ends in need of it to add it to their definition. I don't oppose that. > However, I don't see why KEYWORDS should accept markup. I also think it > should be moved to back-end definitions instead of "ox.el". Keywords should also be printed in the document as well IMO, e.g. after the abstract. An example of where you need markup: σ-algebra. —Rasmus -- Slowly unravels in a ball of yarn and the devil collects it
[O] yasnippet: extra space after first character when expanding snippet (was: Org-mode and YASnippet)
* Marcin Borkowski wrote: > Hello, > > does anyone use YASnippet with Org? I tried, but ran into a strange > problem: when I type into a placeholder field, I get a space after each > letter. Did anyone run into this, too? I do get this behavior on one of my snippets only. And only for the first field. Maybe it's related to https://github.com/capitaomorte/yasnippet/issues/362 I have no solution so far. However, when I paste the text via C-y instead of typing, I don't get this extra space :-O -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] Citation syntax: a revised proposal
0 Parts I like: 1) a parenthetical citation for a single work with no prefix and suffix may be written by just surrounding the key with brackets, like: [@Doe99]. 2) an in-text citation for a single work with no prefix and suffix may be written as a /bare/ key, without brackets, like: @Doe99. I recently cracked up something similar for a paper we are working on, and I think it's nice. I have yet to get the verdict from my coauthor, though. Parts that I don't care for: [cite: whatever (@Doe99) whatever] Not intuitive to me, but I could get used to it. 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. `%%( ... )'. Just too odd. Extensibilty should not be delegated to some weird construct outside of the element in question. —Rasmus -- A page of history is worth a volume of logic
Re: [O] Why not push?
Marcin Borkowski writes: > On 2015-02-15, at 11:42, Eric Abrahamsen wrote: > >> Nicolas Goaziou writes: >> >>> Hello, >>> >>> Marcin Borkowski writes: >>> 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? >>> >>> No. Good luck with refactoring "org.el". ;) >> >> Shhh... if you don't say anything, he might go and do it! > > ;-) > > Actually, not. (Though it might make a nice student project. And it > would be a good idea to do it.) But I haven't signed the FSF papers. > > OTOH, I have a personal project where I devote some amount of time every > day to read someone else's code. I started with parts of simple.el, and > now the time has come for ox-latex (and its dependencies). Ah well, maybe we'll trick someone else into it :) My own personal project is to spend a bit of every day working on the emacs packages that make my computing life possible: Org, Gnus, and BBDB. I'd prefer to spend most of it on Org, but the fact is that when your email setup is broken, that always takes priority. Org and Gnus both suffer (and both benefit) from wild and messy codebases. Org has Nicolas to help whip it into shape; Gnus doesn't. If you're just reading code, ox-latex is a great place to start. If you're fixing code, org-agenda could use some love... Eric
Re: [O] ox and links to equation
Rasmus writes: > I definitely think it is the more proper way to refer to an equation. But > it really depends on the document. E.g. mathtools also offer a set of > commands for referring to equations. I was considering an alist of > > (DESTINATION-TYPE REF-CMD-WITH-DESCRIPTION REF-CMD-WITHOUT-DESCRIPTION) > > But it might be an overkill, especially seeing that mathjax only supports > \ref and \eqref out of the box. It really seems overkill. Note that you can write ([[eq1]]), too. Anyway, you can add another case in `org-latex-link' (fuzzy links part) if you think it is important to support \eqref. Regards,
Re: [O] [patch, ox-latex] better hyperref and title options
Rasmus writes: > 'Cause usually org-export-data gives you the right value automatically. > Anyway, I don't mind using org-element-parse-secondary-string. `org-element-parse-secondary-string' is meant for cases like this one. >> DESCRIPTION could be moved to `org-element-document-properties'. But >> then, we need to introduce `org-export-with-description', which implies >> export back-ends have to deal with it somehow (ATM "ox-ascii" ignores >> it). > >> Another option is to simply remove DESCRIPTION from "ox.el" and let >> export back-ends in need of it to add it to their definition. > > I don't oppose that. > >> However, I don't see why KEYWORDS should accept markup. I also think it >> should be moved to back-end definitions instead of "ox.el". > > Keywords should also be printed in the document as well IMO, e.g. after > the abstract. An example of where you need markup: σ-algebra. Good point. Since KEYWORDS and DESCRIPTION are really back-end dependant, I vote for moving them from `org-export-options-alist' to back-end definitions. Using `org-element-parse-secondary-string' will be required in this case. WDYT? Also, supposing you agree, do you want to do a patch (caveat: there's "org.texi" messing involved)? Regards,
Re: [O] ox and links to equation
Nicolas Goaziou writes: > It really seems overkill. Note that you can write ([[eq1]]), too. What I tried to say in the first email. If I add my patch, which indeed just adds a clause to org-latex-link, it would break documents which uses the above. Regarding the orgmode.org hosted version of mathjax: who should I ping to update it (or can I do it?), and *why* is orgmode.org hosting it? Privacy? >From http://docs.mathjax.org/en/latest/start.html: > We recommend using the CDN service if you can, but you can also install > MathJax on your own server, or locally on your own hard disk. To do so > you will need to do the following things: —Rasmus -- ツ
Re: [O] [patch, ox-latex] better hyperref and title options
Nicolas Goaziou writes:
> Since KEYWORDS and DESCRIPTION are really back-end dependant, I vote for
> moving them from `org-export-options-alist' to back-end definitions.
> Using `org-element-parse-secondary-string' will be required in this
> case.
OK.
So are there any /other/ uses of DESCRIPTION but adding summaries to
meta-data?
> WDYT? Also, supposing you agree, do you want to do a patch (caveat:
> there's "org.texi" messing involved)?
Sure, I'll add it to my TODO. You'll suffer through the reviewing, so in
either case the lion share of work will fall on you.
Without much thought, these are the back-ends where it might make sense:
ox-latex, ox-html, ox-texi, ox-odt, maybe ox-groff.
In a second round, I might add a :with-keywords as well. When non-nil
keywords are inserted at the location of keywords. Like #+TOC. So you'd
have:
#+begin_abstract
Read my paper, pretty please.
#+end_abstract
#+keywords: topic1, ⋯, topicN
→ (If using ox-latex)
\begin{abstract} read me \end{abstract}
\keywords{topic1, ⋯, topicN}
Where \keywords{·} is some function that I don't know yet.
—Rasmus
--
C is for Cookie
Re: [O] [patch, ox-latex] better hyperref and title options
Rasmus writes: > So are there any /other/ uses of DESCRIPTION but adding summaries to > meta-data? I can't think of any. > Without much thought, these are the back-ends where it might make sense: > ox-latex, ox-html, ox-texi, ox-odt, maybe ox-groff. > > In a second round, I might add a :with-keywords as well. It isn't necessary to add :with-description and :with-keywords since :description and :keywords will not belong to "ox.el" anymore. Regards,
Re: [O] ox and links to equation
Rasmus writes: > Nicolas Goaziou writes: > >> It really seems overkill. Note that you can write ([[eq1]]), too. > > What I tried to say in the first email. If I add my patch, which indeed > just adds a clause to org-latex-link, it would break documents which uses > the above. It would appear as, e.g., ((2)) indeed. > Regarding the orgmode.org hosted version of mathjax: who should I ping to > update it (or can I do it?) Probably Bastien. > and *why* is orgmode.org hosting it? Privacy? I don't think CDN service was available at the time mathjax support was implemented. IMO, it hardly makes sense to host it now. Regards,
Re: [O] [ox/ox-latex] Footnotes in titles
Hello,
Rasmus writes:
> Consider the following example
>
> #+TITLE: [ox-latex, bug] footnotes in titles[fn:1]
> #+AUTHOR: Rasmus[fn:2]
>
> [fn:1] I'd like to thank Nicolas for considering this bug
> [fn:2] spammer of the org mailing list
>
> The desired ox-latex output is something like:
>
> \author{Rasmus\thanks{spammer of the org mailing list}}
> \title{[ox-latex, bug] footnotes in titles%
> \thanks{I'd like to thank Nicolas for considering this bug}}
>
> But actual output is something like:
>
> \author{Rasmus\footnotemark[nil]{}}
> \date{\today}
> \title{[ox-latex, bug] footnotes in titles\footnotemark[nil]{}}
>
> It's not too bad: ox-html breaks on this document.
>
> I guess it's a limitation of org-element, since
>
> (org-element-map (org-element-parse-buffer) 'footnote-reference
> (lambda (fn) (org-element-property :label fn)))
> => ("fn:2")
>
> Footnote in titles are often used for acknowledgments.
> Footnote for authors are sometimes for associations.
>
> Is the current treatment the desired treatment?
In fact, I have a local branch that tries to properly support footnotes
in TITLE. However, I don't think it can work in the general case.
Indeed, there is no way for the export process to know whether the title
is going to be exported or not. Note that :with-title is not sufficient,
because the export back-end may ignore its value. Current export could
also be "body only", but, again, some back-ends may use title within
body, and not template. During a "subtree" export, the TITLE keyword
could be overridden by an EXPORT_TITLE property...
If the export process cannot have this information,
`org-export-get-footnote-number' and
`org-export-footnote-first-reference-p' return values are not reliable
anymore.
As a consequence, I have /another/ local branch that disables footnotes
in keywords altogether.
Regards,
--
Nicolas Goaziou
Re: [O] Citation syntax: a revised proposal
Hi Tom,
t...@tsdye.com (Thomas S. Dye) writes:
> 0
>
> A syntax that relegates citation commands to an extension that might not
> export properly in future versions of Org mode isn't useful in my work.
Sorry to disappoint!
I tried really hard to represent in the [cite: ...] syntax all the
particular cases of citation commands that people said were important,
including the ones you suggested. But maybe I missed something, or
maybe you have other suggestions. If so, I am happy to try again.
It is true that the [cite: ...] syntax does not support specifying an
arbitrary citation command. The point of this is to keep the number of
features that Org would initially commit to making work in all backends
at a reasonable level, while still encompassing all the important cases.
If you need arbitrary extensions, that is what the %%(...) part of the
syntax is for. Let me try to clarify what I was thinking about this,
since I didn't say much about it in the proposal. I don't know if this
will address your concern, but I hope it will at least partly do so.
Basically, I'm thinking of the %%(...) part of the syntax as a kind of
playground; it represents `everything we haven't decided about yet', and
is meant to encompass both user-extensions and backend-specific
extensions.
If we treat %%(...) as an arbitrary s-expression, then it should already
be flexible enough to allow people who need even the most esoteric
citation commands to implement them via export filters. But like all
user extensions that execute arbitrary code on arbitrary data, Org is
not in a position to *guarantee* that it will work forevermore. (For
example, your filter might call an Org function that could one day be
removed or renamed, at which point it will break.) Hence this warning:
> *At least for now*, any information supplied this way is /strictly the
> user's responsibility/ to interpret (e.g., using an export filter).
> This means that citations that have information like this are not
> portable and might not be exported correctly:
> - in other users' setups
> - by particular backends
> - by future versions of Org
Note that exactly the same warning applies to links with custom types
and similar user extensions, even if the manual is less explicit about
it. In practice, I expect that the information in %%(...) clauses will
be at least as stable and portable as information in custom links.
(By the way, just to be super clear: `correctly' in the above warning
means `handling the extra information correctly'. I didn't mean to
imply that even the default export behavior could go awry.)
Eventually, we may find that lots of people have similar needs that they
are dealing with in %%(...) syntax. At that point, we may want to adopt
stricter conventions for some parts of this syntax. For example, I
assume we might eventually want a convention that the LaTeX backend will
correctly handle properties that look like:
%%(... :attr_latex (:command "\somecitecommand[%PRE][%POST]{%KEY}") ...)
Once such a convention is discussed and adopted, Org could then
officially support it, and the above warning would no longer apply,
except the part about other backends.
Likewise, if we find cases that are important enough that they need to
work on all backends, representations for those cases could be added to
the [cite: ...] part of the syntax.
So really, the idea I had in splitting the syntax into [cite: ...] and
%%(...) was to give us a good starting point that can be built on in the
future -- not to relegate important features to the dustbin. Sorry that
I did not make that clearer in the proposal!
Best,
Richard
Re: [O] [patch, ox-latex] better hyperref and title options
Nicolas Goaziou writes: > It isn't necessary to add :with-description and :with-keywords > since :description and :keywords will not belong to "ox.el" anymore. :With-keywords is still needed if they can be printed in both the text and the meta data. Keywords are also useful for weblogs, another thing that I'd like to improve. This amounts to provide a couple of extra :sitemap functions: one for generating an index based on summaries in files, e.g. abstract blocks, and partial indexes based on keywords. The output structure would be ./index.html ./keyword1/index.html. Anyway, I don't have any code for this yet. But the point is keywords are important and Org can leverage them better and :with-keywords (even if implemented in ox-WHATEVER.el) is important. —Rasmus -- Sådan en god dansk lagereddike kan man slet ikke bruge mere
Re: [O] Citation syntax: a revised proposal
Hi Rasmus, Rasmus writes: > 0 > > Parts I like: > >1) a parenthetical citation for a single work with no prefix and > suffix may be written by just surrounding the key with brackets, > like: [@Doe99]. >2) an in-text citation for a single work with no prefix and suffix > may be written as a /bare/ key, without brackets, like: @Doe99. > > I recently cracked up something similar for a paper we are working on, and > I think it's nice. I have yet to get the verdict from my coauthor, > though. Cool. :) > Parts that I don't care for: > > [cite: whatever (@Doe99) whatever] > > Not intuitive to me, but I could get used to it. It's not super intuitive to me either, and it just occurred to me yesterday, so maybe there's a better way. The reason I went this way was so that we could represent the difference between parenthetical and in-text citations without moving the cite key and without using different tags (citet: vs. citep:). That makes it easy to write a function that will quickly switch a citation between the two styles, without using the tag to express the difference, which Nicolas was worried would slow down the parser. > 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. The `@' is vestigial inspiration from Pandoc, and is used infrequently enough elsewhere in Org syntax that Nicolas at one point said it would be OK performance-wise to have `@key' appear alone in the text. `&' seemed like a natural counterpart for the same reasons, but I agree it isn't terribly intuitive. (Though maybe there's one supporting intuition: `&' is used to introduce keys in URL parameters...) I disagree with you about the hyphen, but I wouldn't use it enough to lobby for it (it is just vestigial Pandoc). If others think we should take it out, that's fine with me. > `%%( ... )'. > > Just too odd. Extensibilty should not be delegated to some weird > construct outside of the element in question. Again, I don't exactly love this either, but I chose this syntax because %%(...) is already used elsewhere in Org to represent embedded s-expressions (notably in timestamps -- see section 8.1 of the manual). %(...) is also used for s-expressions in capture templates, though I'm not sure why the first case uses two `%'s and the second only one. The only reason to use these delimiters is consistency; I'm not opposed to something prettier if there's a better alternative. Keeping this part of the syntax outside the [cite: ...] brackets allows it to be used with bare keys for simple in-text citations, and prevents a further syntactic restriction on prefix/suffix text inside the brackets. I'm not opposed to moving it inside if that seems really important, but these two considerations weigh against it in my opinion. Best, Richard
Re: [O] Citation syntax: a revised proposal
Hello, Richard Lawrence writes: > 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. > > This proposal represents my attempt to formulate a syntax that is easy > to read, easy to parse, and covers all the use-cases that people > mentioned as being important. It is surely not perfect, but I learned a > lot from the previous thread, and I hope something like this will serve > the community's needs. Thanks for your proposal. Some comments follow. > The difference between parenthetical and in-text citations is > expressed using parentheses around the /first/ citation key. A > parenthetical citation has such parentheses around the first citation > key; an in-text citation lacks them. (Parentheses around non-initial > keys are permitted for visual consistency and to keep the grammar > simple, but have no meaning.) I think it would be nicer to differentiate between in-text and parenthetical citations at the type level, e.g.: [cite: this @key citation is in-text] [(cite): this @key citation is parenthetical] or, as already suggested [citet: ...] [citep: ...] I prefer the former. > 1) a parenthetical citation for a single work with no prefix and > suffix may be written by just surrounding the key with brackets, > like: [@Doe99]. > 2) an in-text citation for a single work with no prefix and suffix > may be written as a /bare/ key, without brackets, like: @Doe99. > (Thus, in both of the `simple' cases, one less level of bracketing is > required.) Sounds good. > *** Syntax for extensions > Additional information can be supplied in a citation that may affect > how export filters or particular backends format it. > > This additional information may be supplied following the brackets of > a citation between the following delimiters: `%%( ... )'. As pointed out, this is very odd. But I cannot see any clean solution. However, it would be nice to integrate it somehow with the syntax. Maybe something like [cite: ... @key ...; ... @key2 ... |latex: :prop val |html: :prop val] > ** Outstanding issues > It seems to me that there are potential problems with the above > proposal in a number of areas, but I cannot tell how serious they are, > or what changes (if any) should be made to solve them. I don't > pretend that this is an exhaustive list: > 1) *Nesting.* I have favored LaTeX compatibility for in-text > citations with multiple references; but this means there is no > way to `nest' citations. Thus, there is no way to express (in > the main syntax) what Pandoc expresses as: > @Doe99 [p. 34; see also @DoeRoe2000] > which renders like: > Doe (1999, p. 34; see also Doe and Roe 2000) > Instead, since a citation is in-text or parenthetical as a whole, > the equivalent in the above syntax > [cite: @Doe99 p. 34; see also @DoeRoe2000] > should render like: > Doe (1999, p. 34), see also Doe and Roe (2000). > I am not certain if Pandoc-like output is important in this case. > The few people who commented on this said that it was not. AFAIU, when using in-text citation, only the first key is extracted out of the parenthesis, so [cite: @Doe99 p. 34; see also @DoeRoe2000] should really render like Doe (1999, p. 34; see also Doe and Roe 2000). IOW, why do you think that "a citation is in-text or parenthetical as a whole"? > 2) *Limitations on prefixes and suffixes.* There may be legitimate > uses of `@', `;', `]', etc. inside prefix or suffix text that the > above syntax does not allow. Examples might include: > - use of semi-colons as part of the prefix/suffix text > - footnotes, links, or timestamps inside a prefix/suffix > I am not certain how important these cases are. If they are > important, some of them might be able to be worked around with > entities. Indeed. Entities are the way to go. If it isn't sufficient we'll need to provide an escaping mechanism. This may be used elsewhere in Org. > 4) *Citation commands.* Rather than introduce an explicit > representation for different citation commands/types, I have used > different parts of the syntax to express the common distinctions > that people mentioned. I suggest that, for now, anything beyond > these basic distinctions be left to the user-extension syntax. > However, if it becomes clear in the future that there is a need > to add a representation for a command to the main syntax, there > is a natural place to do so: immediately after the `cite:' tag > (as Nicolas suggested). With extensions, it is not necessary to support another location for commands. E.g., [cite: @Doe |latex: :command citedwim] or whatever extension syntax is chosen. > Also, I have not said anything in thi
Re: [O] Citation syntax: a revised proposal
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.
Honestly, Org is already full of cryptic symbols, e.g., {{{...}}}
@@...@@, <<<>>>, <<...>>, and so on. This is not worse than the rest
of Org.
Regards,
Re: [O] including files and org-src-preserve-indentation
Hello, Linus Arver writes: >> When I call org-publish-current-project, the included file's TAB >> characters automatically become converted into spaces. Is there an >> orgmode way of preventing this auto-conversion? I cannot reproduce it. Could you provide an ECM? Also, what happens if you do a regular export (no publishing)? Regards, -- Nicolas Goaziou
Re: [O] Citation syntax: a revised proposal
Nicolas Goaziou writes:
>> The difference between parenthetical and in-text citations is
>> expressed using parentheses around the /first/ citation key. A
>> parenthetical citation has such parentheses around the first citation
>> key; an in-text citation lacks them. (Parentheses around non-initial
>> keys are permitted for visual consistency and to keep the grammar
>> simple, but have no meaning.)
>
> I think it would be nicer to differentiate between in-text and
> parenthetical citations at the type level, e.g.:
>
>
> [cite: this @key citation is in-text]
> [(cite): this @key citation is parenthetical]
>
> or, as already suggested
>
> [citet: ...]
> [citep: ...]
>
> I prefer the former.
I prefer the latter. It's explicit, shorter and doesn't hitting shift for
'()' (on my kb). No voodoo. I don't mind either, though.
>
>> *** Syntax for extensions
>> Additional information can be supplied in a citation that may affect
>> how export filters or particular backends format it.
>>
>> This additional information may be supplied following the brackets of
>> a citation between the following delimiters: `%%( ... )'.
>
> As pointed out, this is very odd. But I cannot see any clean solution.
> However, it would be nice to integrate it somehow with the syntax. Maybe
> something like
>
> [cite: ... @key ...; ... @key2 ... |latex: :prop val |html: :prop val]
I prefer to have more expressive keys, e.g. the 'cite' part. But perhaps
it's a good way express extra properties. The thing is, for latex the
extra property is a citation type.
> AFAIU, when using in-text citation, only the first key is extracted out
> of the parenthesis, so
>
> [cite: @Doe99 p. 34; see also @DoeRoe2000]
>
> should really render like
>
> Doe (1999, p. 34; see also Doe and Roe 2000).
>
> IOW, why do you think that "a citation is in-text or parenthetical as
> a whole"?
No! I believe (but correct me if I'm wrong) that neither John, Eric, Tom
nor myself have seen a citation like this in the wild. If you have I
might be wrong. It's no easily supported in latex. The latex equivalent
of the above is:
\citeauthor{doe} (\citeyear[p.\ 34]{doe}; see also \textcite*{roe})
Or something like that.
AFAIK,
[cite: @Doe99 p. 34; see also @DoeRoe2000]
→ Doe (1999, p. 34) and see also Doe et al (2000)
or maybe
Doe (1999, p. 34) and Doe et al (see also 2000).
I don't remember.
—Rasmus
--
Together we'll stand, divided we'll fall
Re: [O] Citation syntax: a revised proposal
Rasmus writes:
> Nicolas Goaziou writes:
>> I think it would be nicer to differentiate between in-text and
>> parenthetical citations at the type level, e.g.:
>>
>>
>> [cite: this @key citation is in-text]
>> [(cite): this @key citation is parenthetical]
>>
>> or, as already suggested
>>
>> [citet: ...]
>> [citep: ...]
>>
>> I prefer the former.
>
> I prefer the latter.
OK.
> It's explicit,
No, sir. (cite) is explicit. It means "a citation enclosed within
parenthesis". citep is only explicit if you come from LaTeX world.
> shorter
cite and (cite) have the same mean length!
> and doesn't hitting shift for '()' (on my kb).
OK. "Rasmus' keyboard" (aka. a Rk) is a decent unit of measurement for
syntax quality, I guess. ;)
> No voodoo. I don't mind either, though.
What colour are voodoo sheds these days?
>> As pointed out, this is very odd. But I cannot see any clean solution.
>> However, it would be nice to integrate it somehow with the syntax. Maybe
>> something like
>>
>> [cite: ... @key ...; ... @key2 ... |latex: :prop val |html: :prop val]
>
> I prefer to have more expressive keys, e.g. the 'cite' part.
Please don't touch (too much) the "cite" part. This is for Org, not for
export back-ends.
> But perhaps it's a good way express extra properties. The thing is,
> for latex the extra property is a citation type.
Then
[cite: ... |latex: :type citedwim]
How many "Rk" does this score?
>> AFAIU, when using in-text citation, only the first key is extracted
>> out of the parenthesis, so
>>
>> [cite: @Doe99 p. 34; see also @DoeRoe2000]
>>
>> should really render like
>>
>> Doe (1999, p. 34; see also Doe and Roe 2000).
>>
>> IOW, why do you think that "a citation is in-text or parenthetical as
>> a whole"?
>
> No! I believe (but correct me if I'm wrong) that neither John, Eric, Tom
> nor myself have seen a citation like this in the wild. If you have I
> might be wrong. It's no easily supported in latex. The latex equivalent
> of the above is:
>
> \citeauthor{doe} (\citeyear[p.\ 34]{doe}; see also \textcite*{roe})
>
> Or something like that.
>
> AFAIK,
> [cite: @Doe99 p. 34; see also @DoeRoe2000]
> → Doe (1999, p. 34) and see also Doe et al (2000)
> or maybe
>Doe (1999, p. 34) and Doe et al (see also 2000).
>
> I don't remember.
OK. Then let's forget about my remark.
Regards,
Re: [O] Citation syntax: a revised proposal
Hi Nicolas,
Thanks for your comments. A couple of replies follow.
Nicolas Goaziou writes:
>> The difference between parenthetical and in-text citations is
>> expressed using parentheses around the /first/ citation key. A
>> parenthetical citation has such parentheses around the first citation
>> key; an in-text citation lacks them. (Parentheses around non-initial
>> keys are permitted for visual consistency and to keep the grammar
>> simple, but have no meaning.)
>
> I think it would be nicer to differentiate between in-text and
> parenthetical citations at the type level, e.g.:
>
>
> [cite: this @key citation is in-text]
> [(cite): this @key citation is parenthetical]
>
> or, as already suggested
>
> [citet: ...]
> [citep: ...]
>
> I prefer the former.
Either of these is fine with me if it is OK with you. I was trying to
avoid any variation in the position after `[' to reduce strain on the
parser, but if these are simple enough to support without too many false
positives, even better.
>> This additional information may be supplied following the brackets of
>> a citation between the following delimiters: `%%( ... )'.
>
> As pointed out, this is very odd. But I cannot see any clean solution.
As I said in reply to Rasmus, my only reason for this choice was to be
consistent with the s-expression syntax in timestamps and capture
templates. I am fine with (and even would prefer) something that looks
prettier.
> However, it would be nice to integrate it somehow with the syntax. Maybe
> something like
>
> [cite: ... @key ...; ... @key2 ... |latex: :prop val |html: :prop val]
>
But I think there are three reasons this does not quite improve on what
I proposed:
1) It looks like it only supports properties directed at specific
backends. How should users specify custom properties that they want to
be handled in multiple backends (by their own filter)?
2) It requires us to decide *now* on conventions for specifying
properties to specific backends (and also to build a parser for them,
instead of just calling `read'), instead of just using arbitrary
s-expressions and seeing what people come up with in the future. (See
my reply to Tom for more about how I was thinking this part of the
syntax would evolve.)
3) Putting the properties inside the brackets introduces an (admittedly
very minor) additional restriction on suffix text, and can't be used
with the simple syntax for in-text citations. (See my reply to Rasmus
on this point.)
That said, I have no objections to doing something like this if we can
come to an agreement now about what it should look like.
>> ** Outstanding issues
>> It seems to me that there are potential problems with the above
>> proposal in a number of areas, but I cannot tell how serious they are,
>> or what changes (if any) should be made to solve them. I don't
>> pretend that this is an exhaustive list:
>> 1) *Nesting.* I have favored LaTeX compatibility for in-text
>> citations with multiple references; but this means there is no
>> way to `nest' citations. Thus, there is no way to express (in
>> the main syntax) what Pandoc expresses as:
>> @Doe99 [p. 34; see also @DoeRoe2000]
>> which renders like:
>> Doe (1999, p. 34; see also Doe and Roe 2000)
>> Instead, since a citation is in-text or parenthetical as a whole,
>> the equivalent in the above syntax
>> [cite: @Doe99 p. 34; see also @DoeRoe2000]
>> should render like:
>> Doe (1999, p. 34), see also Doe and Roe (2000).
>> I am not certain if Pandoc-like output is important in this case.
>> The few people who commented on this said that it was not.
>
> AFAIU, when using in-text citation, only the first key is extracted out
> of the parenthesis, so
>
> [cite: @Doe99 p. 34; see also @DoeRoe2000]
>
> should really render like
>
> Doe (1999, p. 34; see also Doe and Roe 2000).
>
> IOW, why do you think that "a citation is in-text or parenthetical as
> a whole"?
This is a LaTeX compatibility issue, and it is an area where Pandoc
departs from LaTeX behavior. If you're a LaTeX user, the natural way to
think of the Org syntax you quoted is (I think) as equivalent to one of:
\textcites[p. 34]{Doe99}[see also][]{DoeRoe2000}
\textcite[p. 34]{Doe99}, \textcite[see also][]{DoeRoe2000}
which IIUC both render like
Doe (1999, p. 34), see also Doe and Roe (2000).
modulo some subtle details about the separator. No one so far has said
that they need or want the Pandoc behavior. I personally am fine
without it.
Best,
Richard
Re: [O] Citation syntax: a revised proposal
Richard Lawrence writes: >> However, it would be nice to integrate it somehow with the syntax. Maybe >> something like >> >> [cite: ... @key ...; ... @key2 ... |latex: :prop val |html: :prop val] >> > > But I think there are three reasons this does not quite improve on what > I proposed: > > 1) It looks like it only supports properties directed at specific > backends. How should users specify custom properties that they want to > be handled in multiple backends (by their own filter)? They cannot (unless they want to use something like "|custom: ..."). Note they cannot either for regular elements using attributes. The reason is that multiple back-end properties are very rare. For example, :width hasn't the same unit in "ox-latex" and "ox-html". > 2) It requires us to decide *now* on conventions for specifying > properties to specific backends Indeed. This is also part of the syntax we're trying to define, isn't it? > (and also to build a parser for them, instead of just calling `read'), We won't be calling "read". OTOH, there's already `org-export-read-attribute', which does a reasonable job. > instead of just using arbitrary s-expressions and seeing what people > come up with in the future. (See my reply to Tom for more about how > I was thinking this part of the syntax would evolve.) The point is that this syntax (which isn't new in this thread, excepted the "|" character) is extensible at will. It can evolve. > 3) Putting the properties inside the brackets introduces an (admittedly > very minor) additional restriction on suffix text, and can't be used > with the simple syntax for in-text citations. (See my reply to Rasmus > on this point.) I don' think this is a real issue. Each back-end can decide what command should be used for simple syntax. It is even possible to provide a defcustom for it. Regards,
Re: [O] Citation syntax: a revised proposal
Hi Nicolas, 2015ko otsailak 15an, Nicolas Goaziou-ek idatzi zuen: >> 1) It looks like it only supports properties directed at specific >> backends. How should users specify custom properties that they want to >> be handled in multiple backends (by their own filter)? > > They cannot (unless they want to use something like "|custom: ..."). > > Note they cannot either for regular elements using attributes. The > reason is that multiple back-end properties are very rare. For > example, :width hasn't the same unit in "ox-latex" and "ox-html". It seems like these might occur for citations. The :capitalize property discussed in the predecessor to this thread is one example. So perhaps there could be a |all: list which would be merged with the backend-specific one(s). Thanks, -- Aaron Ecay
Re: [O] Citation syntax: a revised proposal
Hello,
Aaron Ecay writes:
> Hi Nicolas,
>
> 2015ko otsailak 15an, Nicolas Goaziou-ek idatzi zuen:
>>> 1) It looks like it only supports properties directed at specific
>>> backends. How should users specify custom properties that they want to
>>> be handled in multiple backends (by their own filter)?
>>
>> They cannot (unless they want to use something like "|custom: ...").
>>
>> Note they cannot either for regular elements using attributes. The
>> reason is that multiple back-end properties are very rare. For
>> example, :width hasn't the same unit in "ox-latex" and "ox-html".
>
> It seems like these might occur for citations. The :capitalize property
> discussed in the predecessor to this thread is one example. So perhaps
> there could be a |all: list which would be merged with the
> backend-specific one(s).
Perhaps. But [cite: ... |latex: :cap t |html: :cap t] isn't impossible
to write either.
Anyway, time for another proposal. In fact, it seems that it would be
better to externalize these properties, e.g.,
[cite: ...]{latex :prop val}{html :prop val}
or
[cite: ...]{latex :prop val | html :prop val}
No space allowed between the citation and the attributes. The big
advantage with this is that it can be extended to other objects while
still being backward-compatible.
It would solve one long standing limitation:
Text [[file:img1.png]]{html :width 50px} and
[[file:img2.png]]{html :width 60 px}
Regards,
Re: [O] Citation syntax: a revised proposal
Rasmus writes: >> or, as already suggested >> >> [citet: ...] >> [citep: ...] >> >> I prefer the former. > > I prefer the latter. It's explicit, shorter and doesn't hitting shift for > '()' (on my kb). No voodoo. I don't mind either, though. Nobody should be typing these by hand anyway ;) you should have a nice key binding (preferrably with a prefix arg) that helps you select from a database, and inserts the formatted key in the right syntax for the vast majority of the time. -- 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
Hi Nicolas,
2015ko otsailak 15an, Nicolas Goaziou-ek idatzi zuen:
> Perhaps. But [cite: ... |latex: :cap t |html: :cap t] isn't impossible
> to write either.
It violates DRY. It (thus) makes it annoying to export a document to a
new backend: you have to search through all the citations and copy any
:cap keys to the new backend.
Crazy idea: what if there was a “root” backend from which all other
backends were derived? This would maintain consistency with existing
attribute syntax (and possibly new, as proposed below), but also allow
certain attributes to be passed to all backends.
>
> Anyway, time for another proposal. In fact, it seems that it would be
> better to externalize these properties, e.g.,
>
> [cite: ...]{latex :prop val}{html :prop val}
>
> or
>
> [cite: ...]{latex :prop val | html :prop val}
>
> No space allowed between the citation and the attributes. The big
> advantage with this is that it can be extended to other objects while
> still being backward-compatible.
>
> It would solve one long standing limitation:
>
> Text [[file:img1.png]]{html :width 50px} and
> [[file:img2.png]]{html :width 60 px}
Nice, I like it.
Thanks,
--
Aaron Ecay
Re: [O] Citation syntax: a revised proposal
Hi Richard, Thanks for your thoughtful response. I had indeed misunderstood the bit about not being able to export in future versions of Org mode. Thanks for the clarification. However, I'm still 0 because our goals are different. I want a syntax that recognizes arbitrary citation commands because I write in Org mode for publication. You want a syntax that recognizes a few commands that it might be possible to support in Org mode backends, some of which are tied loosely, if at all, to publication. Yours might be a noble goal that many Org mode users will find useful (I hope it is!), but I don't think it is (or will be) a syntax useful in my work, for the following reasons: 1) It is easier for me to have the citation command in one place. The decision to represent selected aspects of the citation command in the syntax and other parts in extensions means that I'd have to learn the syntax and then remember which aspects were chosen for representation and which I'd need to develop through extensions of my own. This is a lot more work than I do now to get exactly what I want through links. I'm keen to simplify the authoring process, not make it more complex. 2) Treating footnote citations differently from author-date citations is a non-starter for me. When Science turns me away and the editor suggests that my rant is well suited for another journal, one that happens to use author-date citations, I'll just search all my citation links and replace footcite with parencite before exporting the rant to the suggested journal. IIUC, with the official Org mode syntax, I'd be faced with the tedious process of cutting and pasting footnote text back into the document body. Also, I'm 0 because there is no need to satisfy me with the official citation syntax. I'm able to achieve my goals fully in Org mode without it. All the best, Tom Richard Lawrence writes: > Hi Tom, > > t...@tsdye.com (Thomas S. Dye) writes: > >> 0 >> >> A syntax that relegates citation commands to an extension that might not >> export properly in future versions of Org mode isn't useful in my work. > > Sorry to disappoint! > > I tried really hard to represent in the [cite: ...] syntax all the > particular cases of citation commands that people said were important, > including the ones you suggested. But maybe I missed something, or > maybe you have other suggestions. If so, I am happy to try again. > > It is true that the [cite: ...] syntax does not support specifying an > arbitrary citation command. The point of this is to keep the number of > features that Org would initially commit to making work in all backends > at a reasonable level, while still encompassing all the important cases. > > If you need arbitrary extensions, that is what the %%(...) part of the > syntax is for. Let me try to clarify what I was thinking about this, > since I didn't say much about it in the proposal. I don't know if this > will address your concern, but I hope it will at least partly do so. > > Basically, I'm thinking of the %%(...) part of the syntax as a kind of > playground; it represents `everything we haven't decided about yet', and > is meant to encompass both user-extensions and backend-specific > extensions. > > If we treat %%(...) as an arbitrary s-expression, then it should already > be flexible enough to allow people who need even the most esoteric > citation commands to implement them via export filters. But like all > user extensions that execute arbitrary code on arbitrary data, Org is > not in a position to *guarantee* that it will work forevermore. (For > example, your filter might call an Org function that could one day be > removed or renamed, at which point it will break.) Hence this warning: > >> *At least for now*, any information supplied this way is /strictly the >> user's responsibility/ to interpret (e.g., using an export filter). >> This means that citations that have information like this are not >> portable and might not be exported correctly: >> - in other users' setups >> - by particular backends >> - by future versions of Org > > Note that exactly the same warning applies to links with custom types > and similar user extensions, even if the manual is less explicit about > it. In practice, I expect that the information in %%(...) clauses will > be at least as stable and portable as information in custom links. > > (By the way, just to be super clear: `correctly' in the above warning > means `handling the extra information correctly'. I didn't mean to > imply that even the default export behavior could go awry.) > > Eventually, we may find that lots of people have similar needs that they > are dealing with in %%(...) syntax. At that point, we may want to adopt > stricter conventions for some parts of this syntax. For example, I > assume we might eventually want a convention that the LaTeX backend will > correctly handle properties that look like: > > %%(... :attr_latex (:command "\somecitecommand[%PRE][%P
Re: [O] Citation syntax: a revised proposal
Aaron Ecay writes: > It violates DRY. It (thus) makes it annoying to export a document to a > new backend: you have to search through all the citations and copy any > :cap keys to the new backend. > > Crazy idea: what if there was a “root” backend from which all other > backends were derived? This would maintain consistency with existing > attribute syntax (and possibly new, as proposed below), but also allow > certain attributes to be passed to all backends. The model doesn't hold because attributes are not inherited. Anyway I'm not against adding a special "all" attribute, but if it can be avoided, I'm all for it. Time for another crazy idea. Last one on my side for today [cite ...] [(cite) ...] [Cite ...] [(Cite) ...] It should solve the :capitalize issue. Regards,
Re: [O] Citation syntax: a revised proposal
Nicolas Goaziou writes: > [cite ...] [(cite) ...] [Cite ...] [(Cite) ...] > > It should solve the :capitalize issue. This is what biblatex does. —Rasmus -- . . . The proofs are technical in nature and provides no real understanding
Re: [O] [ox/ox-latex] Footnotes in titles
Nicolas Goaziou writes: > Indeed, there is no way for the export process to know whether the title > is going to be exported or not. Note that :with-title is not sufficient, > because the export back-end may ignore its value. Current export could > also be "body only", but, again, some back-ends may use title within > body, and not template. During a "subtree" export, the TITLE keyword > could be overridden by an EXPORT_TITLE property... 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. Footnotes in EXPORT_TITLE properties would be weird. I don't know if you can have that. You tell me. —Rasmus -- Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!
Re: [O] ox and links to equation
Nicolas Goaziou writes:
> It would appear as, e.g., ((2)) indeed.
So what's the verdict? The upside is that \eqref{·} is more robust.
>> and *why* is orgmode.org hosting it? Privacy?
>
> I don't think CDN service was available at the time mathjax support was
> implemented. IMO, it hardly makes sense to host it now.
OK, I'll see if I try to make it point to the mathjax CDN and add the
option that enables \ref{·} and \eqref{·}.
—Rasmus
--
If you can mix business and politics wonderful things can happen!
Re: [O] ox and links to equation
Rasmus writes:
>> It would appear as, e.g., ((2)) indeed.
>
> So what's the verdict? The upside is that \eqref{·} is more robust.
Your call. You face the consequences. Alone.
I think this is safe to make the change as long as there is a ORG-NEWS
entry. Of course, I never wrote that last sentence.
Regards,
Re: [O] Citation syntax: a revised proposal
I guess this looks workable. The syntax is generally more verbose than I am accustomed to, and less explicit in my (latex centric) opinion. But, the majority of our citations would be the simplest form, which is maybe even shorter. It looks like the citation insertion could be practically automated, e.g. a command with a convenient key-binding looks up references in some database, selects them, and then inserts them as properly formatted citations at point. 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. 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. Not because of any syntax reason, but a functional one. Right now every link-based citation is a one click gateway to every scientific search engine I know, the pdf, the bibtex entry, functions that copy citations, summarize citations, email citations, etc... for the key that was clicked on. That is too useful to give up for any syntax. But if each key was clickable, to a user-definable, or default function (which might even be nothing), then no problem. Probably the user should have to define this function, since a key is no good without getting information about where the database is from somewhere (e.g. a variable or in the file). I gather we are split between bibtex, org-bibtex, and zotero as backends, and maybe there are others (RIS, Mendeley, ...). Maybe one day there is good support for all of them. I have tried them all, and for 15+ years, I keep coming back to bibtex ;) I am a little concerned about what the latex export will eventually look like. Out of the box, I suppose a handful of types will be pretty well supported, something like: (cite, citet, citep, citeauthor, citeyear, citenum) which I suspect would cover many people's needs. 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 ;). 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. 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. Each of these would need customizable export. I am pretty sure those are backend independent (even though I took the names straight from LaTeX ;). With Endnote/Word for example you have to choose a bibliography and style. So, overall, I am on the positive side of zero. Richard Lawrence writes: > 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. > > This proposal represents my attempt to formulate a syntax that is easy > to read, easy to parse, and covers all the use-cases that people > mentioned as being important. It is surely not perfect, but I learned a > lot from the previous thread, and I hope something like this will serve > the community's needs. > > The proposal is below, both inline (for easy quoting) and attached (for > easy reading). To keep it relatively short, I have mostly not explained > my reasoning for the choices I made, but I am happy to do so here if > anyone has questions. > > I welcome feedback, comments, criticisms, and objections on any point. > However, since we've already had a long discussion about this, I > respectfully request that we try to keep this thread focused. To that > end, I suggest: > > 1) If you have criticisms or objections, please try to indicate > whe
[O] key binding for org-inlinetask-insert-task has gone missing?
Hello, nothing major but I am very puzzled and I felt like posting something to this list on a Sunday evening ;-) For some reason, the binding for org-inlinetask-insert-task has disappeared from org-mode-map for me! The command to bind "C-c C-x t" is still there in org-inlinetask.el but that key binding is "undefined" according to "C-h c C-c C-x t". This binding has always worked for me. I use inline tasks all the time. My configuration hasn't changed appreciably for quite some time. org-inlinetask.el has not changed for some time either, by the way. All other bindings that I expect are there in org-mode-map. Has some change been made to the definition of org-mode-map so that I need to require org-inlinetask at a different time during initialisation? This is more about curiosity than requiring a real answer. It's easy enough for me to re-instate this binding in my org-mode-hook... or even invoke it directly with M-x... Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-816-gae83b3
Re: [O] [ox/ox-latex] Footnotes in titles
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. > 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. For now, I pushed the "no footnote reference in keywords" branch, just to be on the safe side wrt CAPTION keywords. We can still discuss about making a special case for TITLE and al. Regards,
Re: [O] Why not push?
On Sun, Feb 15, 2015 at 2:38 AM, Nicolas Goaziou wrote: > No. Good luck with refactoring "org.el". ;) Could you clarify what you think are the biggest issues with refactoring org.el ?
Re: [O] Why not push?
Yuri Niyazov writes: > Could you clarify what you think are the biggest issues with > refactoring org.el ? Its size. Regards,
Re: [O] Why not push?
On 2015-02-15, at 22:22, Yuri Niyazov wrote: > On Sun, Feb 15, 2015 at 2:38 AM, Nicolas Goaziou > wrote: >> No. Good luck with refactoring "org.el". ;) > > Could you clarify what you think are the biggest issues with > refactoring org.el ? IMHO, the biggest and most useful thing would be to divide the humongous functions into smaller, reusable parts. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
On Mon, Jan 19, 2015 at 6:38 PM, Nicolas Goaziou wrote: > Nikolai Weibull writes: > >> On Sun, Jan 18, 2015 at 11:39 PM, Nicolas Goaziou > >>> It could make sense, but the current behaviour is simple and >>> consistent : always refresh manually, no exception. >> >> I don’t agree that this is consistent at all. The Agenda is refreshed >> when you run, for example, org-agenda-filter-by-category, which, in my >> mind, is similar to setting a restriction. > > I didn't know an exception existed. Do you want to provide a patch for > this, then? Hi! Sorry for the late reply. Here’s a patch that should work: diff -u org-agenda.el.orig org-agenda.el --- org-agenda.el.orig2015-01-18 10:31:12.0 +0100 +++ org-agenda.el2015-02-15 22:25:41.0 +0100 @@ -7135,7 +7135,9 @@ (defun org-agenda-maybe-redo () "If there is any window showing the agenda view, update it." - (let ((w (get-buffer-window org-agenda-buffer-name t)) + (let ((w (get-buffer-window (or org-agenda-this-buffer-name + org-agenda-buffer-name) + t)) (w0 (selected-window))) (when w (select-window w)
Re: [O] Why not push?
On 2015-02-15, at 13:26, Eric Abrahamsen wrote: > Ah well, maybe we'll trick someone else into it :) ;-) > My own personal project is to spend a bit of every day working on the > emacs packages that make my computing life possible: Org, Gnus, and > BBDB. I'd prefer to spend most of it on Org, but the fact is that when > your email setup is broken, that always takes priority. Org and Gnus > both suffer (and both benefit) from wild and messy codebases. Org has > Nicolas to help whip it into shape; Gnus doesn't. That is a good one. It wouldn't work for me, though, for reason I've explained earlier. > If you're just reading code, ox-latex is a great place to start. If > you're fixing code, org-agenda could use some love... Well, since I want to write a modification of the LaTeX exporter, ox-latex seems a natural thing to look at. OTOH, org-agenda looks scary ;-). > Eric Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] ox and links to equation
Nicolas Goaziou writes:
>> So what's the verdict? The upside is that \eqref{·} is more robust.
>
> Your call. You face the consequences. Alone.
>
> I think this is safe to make the change as long as there is a ORG-NEWS
> entry. Of course, I never wrote that last sentence.
Thinking some more about it, it's a bad idea, unless one would be able to
tell if it's math environment. Which might require something like
texmathp. Which is not part of Emacs-core.
—Rasmus
--
C is for Cookie
Re: [O] Why not push?
On 2015-02-15, at 12:35, Rasmus wrote: > Marcin Borkowski writes: > >> Hi there, >> >> 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? > > These days you even have split-string in subr which you can make behave > like org-split-string. Interesting. I'll look into it. > Oh, and there's all the cl re-implementations... I like org-some better > than cl-some just cause it sounds nice when you say it (try): Yes, it seems to me that reinventing the wheel is quite common in Emacs libraries. > org (tiny pause) some. At least one lame pun comes to mind... > —Rasmus Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
[O] [patch, ox-html] mathjax changes (was: ox and links to equation)
Hi,
>> and *why* is orgmode.org hosting it? Privacy?
>
> I don't think CDN service was available at the time mathjax support was
> implemented. IMO, it hardly makes sense to host it now.
This patch switches the cdn to upstream and removes a lot of stuff that I
believe mathjax will figure out on it own. I'm no mathjax or webs export,
though. Notably, mathml stuff is gone.
OTOH, I added some display options, which I believe one might care about.
If more "user-sensible" options exists I can add them.
It would be good if someone who knows MathJax better could reviews this.
—Rasmus
--
When the facts change, I change my mind. What do you do, sir?
>From baf1f93056feb034c223cc7d7f5234559cd34471 Mon Sep 17 00:00:00 2001
From: Rasmus
Date: Mon, 16 Feb 2015 02:04:02 +0100
Subject: [PATCH] ox-html: Use upstream MathJax CDN
* ox-html.el (org-html-mathjax-options): Add multlinewidth,
autonumber, tagindent and tagside. Remove MathML. Change
default indent to correspond to upstream default. Change
default MathJax path to point to upstream CDN.
(org-html--build-mathjax-config): Remove MathML-related parts.
(org-html-mathjax-template): Simplifiy template.
* org.texi (@LaTeX{} fragments), (Math formatting in HTML export):
Reflect change in default CDN.
---
doc/org.texi| 51 -
lisp/ox-html.el | 115
2 files changed, 73 insertions(+), 93 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index bec46a9..157f928 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -10258,20 +10258,17 @@ format sub- and superscripts in a WYSIWYM way.
Going beyond symbols and sub- and superscripts, a full formula language is
needed. Org mode can contain @LaTeX{} math fragments, and it supports ways
to process these for several export back-ends. When exporting to @LaTeX{},
-the code is obviously left as it is. When exporting to HTML, Org can invoke
-the @uref{http://www.mathjax.org, MathJax library} (@pxref{Math formatting in
-HTML export}) to process and display the math@footnote{If you plan to use
-this regularly or on pages with significant page views, you should install
-@file{MathJax} on your own server in order to limit the load of our server.}.
-It can also process the mathematical expressions into images that can be
-displayed in a browser (see @pxref{Previewing @LaTeX{} fragments}).
+the code is left as it is. When exporting to HTML, Org can use either
+@uref{http://www.mathjax.org, MathJax} (@pxref{Math formatting in HTML
+export}) or transcode the math into images (see @pxref{Previewing @LaTeX{}
+fragments}).
@LaTeX{} fragments don't need any special marking at all. The following
snippets will be identified as @LaTeX{} source code:
@itemize @bullet
@item
-Environments of any kind@footnote{When @file{MathJax} is used, only the
-environments recognized by @file{MathJax} will be processed. When
+Environments of any kind@footnote{When MathJax is used, only the
+environments recognized by MathJax will be processed. When
@file{dvipng} program or @file{imagemagick} suite is used to create images,
any @LaTeX{} environment will be handled.}. The only requirement is that the
@code{\begin} statement appears on a new line, at the beginning of the line
@@ -10307,7 +10304,7 @@ either $$ a=+\sqrt@{2@} $$ or \[ a=-\sqrt@{2@} \].
@vindex org-export-with-latex
@LaTeX{} processing can be configured with the variable
@code{org-export-with-latex}. The default setting is @code{t} which means
-@file{MathJax} for HTML, and no processing for ASCII and @LaTeX{} back-ends.
+MathJax for HTML, and no processing for ASCII and @LaTeX{} back-ends.
You can also set this variable on a per-file basis using one of these
lines:
@@ -11466,25 +11463,23 @@ You could use @code{http} addresses just as well.
@cindex imagemagick
@LaTeX{} math snippets (@pxref{@LaTeX{} fragments}) can be displayed in two
-different ways on HTML pages. The default is to use the
-@uref{http://www.mathjax.org, MathJax system} which should work out of the
-box with Org mode installation because @uref{http://orgmode.org} serves
-@file{MathJax} for Org mode users for small applications and for testing
-purposes. @b{If you plan to use this regularly or on pages with significant
-page views, you should install@footnote{Installation instructions can be
-found on the MathJax website, see
-@uref{http://www.mathjax.org/resources/docs/?installation.html}.} MathJax on
-your own server in order to limit the load of our server.} To configure
-@file{MathJax}, use the variable @code{org-html-mathjax-options} or
-insert something like the following into the buffer:
-
-@example
-#+HTML_MATHJAX: align:"left" mathml:t path:"/MathJax/MathJax.js"
-@end example
+different ways on HTML pages. The default is to use
+@uref{http://www.mathjax.org, MathJax} which should work out of the box with
+Org@footnote{By default Org loads MathJax from
+@uref{http://docs.mathjax.org/en/latest/
Re: [O] Citation syntax: a revised proposal
In On Feb 15, 2015 2:43 PM, "Thomas S. Dye" wrote: > > > 1) It is easier for me to have the citation command in one place. The > decision to represent selected aspects of the citation command in the > syntax and other parts in extensions means that I'd have to learn the > syntax and then remember which aspects were chosen for representation > and which I'd need to develop through extensions of my own. This is a > lot more work than I do now to get exactly what I want through links. > I'm keen to simplify the authoring process, not make it more complex. > > 2) Treating footnote citations differently from author-date citations is > a non-starter for me. When Science turns me away and the editor > suggests that my rant is well suited for another journal, one that > happens to use author-date citations, I'll just search all my citation > links and replace footcite with parencite before exporting the rant to > the suggested journal. IIUC, with the official Org mode syntax, I'd be > faced with the tedious process of cutting and pasting footnote text back > into the document body. 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. Thanks Richard and everyone else for the continued hard work! Matt Matt > Also, I'm 0 because there is no need to satisfy me with the official > citation syntax. I'm able to achieve my goals fully in Org mode without > it. > >
