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)
>
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-lin
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
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.
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
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 docu
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:
>>>
>>> (se
+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 pr
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 upstrea
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
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 usua
* 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
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 br
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 fo
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
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'. B
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 m
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 DESCRIPTIO
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
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 a
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 somethi
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
par
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
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
>
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 m
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., {{{...}}}
@@...@@, <<<>>>, <<
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
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-ini
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
>>
>>
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
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)
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
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 fi
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 ;)
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
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 bec
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? T
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
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
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
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 senten
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
automate
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
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. T
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 ?
Yuri Niyazov writes:
> Could you clarify what you think are the biggest issues with
> refactoring org.el ?
Its size.
Regards,
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 d
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 cons
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,
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 abo
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
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 i
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
53 matches
Mail list logo
