Hello,
· Nicolas Goaziou wrote:
> Hello,
>
> Rasmus writes:
>
>> Thomas Holst writes:
>>
>>> when I try to export an subtree with koma letter I get the following
>>> error:
>>>
>>> cond: Symbol's value as variable is void: with-title
>>>
>>> This seems to be related to the following commit:
On Tue, Jun 16, 2015 at 12:30:09AM +0200, Rasmus wrote:
> Suvayu Ali writes:
>
> > * Fitting technique :B_minipage:
> > :PROPERTIES:
> > :BEAMER_env: minipage
> > :BEAMER_arg: 0.1\linewidth
> > :END:
> > +/cFit/+
>
> The closest would probably be somethin
"Charles C. Berry" writes:
> On Mon, 15 Jun 2015, Rainer M Krug wrote:
>
>> Hi
>>
>> I have a relatively large file with
>> about 200 =source blocks (R) to be tangled to get an R package. But the
>> tangling takes about 20 seconds.
>>
>> Profiling the tangling showed that the call to ~mapcar~ in
Nicolas Goaziou writes:
> Hello,
>
> Rainer M Krug writes:
>
>> I have a relatively large file with
>> about 200 =source blocks (R) to be tangled to get an R package. But the
>> tangling takes about 20 seconds.
>>
>> Profiling the tangling showed that the call to ~mapcar~ in
>> ~org-babel-params
Nicolas Goaziou writes:
> Rainer M Krug writes:
>
>> Thanks for the clarification. Is there a technical or security reason
>> for this? because especially for export, file local variables would make
>> sense to avoid the #+BIND keywords?
>
> ISTR there is a technical reason for this. Under some
Rainer M Krug writes:
> I would not remove it as even I have some org files using them - shame
> on me.
We can check for that in Org Lint and warn the user.
> But what about making it user configurable? a variable
> ~org-babel-tangle-use-deprecated-header-args~ which if set to non-nil would
> e
Hello,
William Denton writes:
> Attached is a tiny patch to add mention of this variable in the
> section of the docs where all those options are listed.
Thank you. Would you mind using git format-patch for it and add a proper
commit message?
Also, wouldn't it make sense to use @vindex org-foo
Hello,
Rasmus writes:
> Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to
> org-beamer--normalize-argument, so the above won't actually work (see
> org-beamer--format-block). From the looks of it I'd be willing to call it
> a bug, but Nicolas may have had something in mind.
I
Hi,
I think I need some refresh on what's valid and what is not.
Assume the following file :
#+TITLE: Foo
#+DATE: 2014-11-19 01:10:58
* FOO
[2015-06-16 mar. 13:58]
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit
tempor tellus. Donec pretium posuere tellus. Proin quam
Hi Nicolas,
On Tue, Jun 16, 2015 at 01:57:06PM +0200, Nicolas Goaziou wrote:
> Rasmus writes:
>
> > Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to
> > org-beamer--normalize-argument, so the above won't actually work (see
> > org-beamer--format-block). From the looks of it I
Nicolas Goaziou writes:
> Rainer M Krug writes:
>
>> I would not remove it as even I have some org files using them - shame
>> on me.
To be clear, are we talking of constructs such as:
--8<---cut here---start->8---
** Subtree
:PROPERTIES:
:tangle: no
Hello,
Fabrice Popineau writes:
> Assume the following file :
[...]
> ** First link
[...]
> ** Second link
> [2015-06-16 mar. 13:58]
>
> - [[First%20link][First link]]
[...]
> The exporter fails to resolve the (fuzzy) link "First%20link".
> However, if I click on the link, I jump to the ri
Hi,
Nicolas Goaziou writes:
>> Unfortunately, BEAMER_OPTs are wrapped in square brackets thanks to
>> org-beamer--normalize-argument, so the above won't actually work (see
>> org-beamer--format-block). From the looks of it I'd be willing to call it
>> a bug, but Nicolas may have had something i
Hello,
Sebastien Vauban
writes:
> To be clear, are we talking of constructs such as:
>
> ** Subtree
>:PROPERTIES:
>:tangle: no
>:END:
>
> ?
Yes, we are.
> Your suggestion with Org-lint, or even writing a function that would
> convert from the old to the new syntax, makes a shorte
On Sun 14 Jun 2015, Johan W. Klüwer wrote:
> I'm having difficulties passing org variables into shell source blocks.
> This is using Windows 7 and Cygwin with bash shell. For instance, the
> following
>
> #+BEGIN_SRC sh :var x="."
> ls $x
> #+END_SRC
>
> fails with the error message (as displaye
Rasmus writes:
> The third argument is hard-coded to 'option in org-beamer--format-block
> ATM.
ox-beamer expects options to be wrapped within square brackets. If they
are not, it does that task. This is a bit drastic, but it works well in
practice.
> Indeed. That's the incremental fix.
Done
2015-06-16 14:50 GMT+02:00 Nicolas Goaziou :
> Hello,
>
>
> So, export process doesn't url-decode links, and cannot handle the link
> above.
This is what I was missing :-)
> At this point, it seems that all is left are cheesy approaches. E.g,
> when a path matches "%[A-Za-z0-9]\\{2\\}", decode
On Tue, Jun 16, 2015 at 03:33:03PM +0200, Nicolas Goaziou wrote:
> Rasmus writes:
>
> > Indeed. That's the incremental fix.
>
> Done in cf5fd31f0c4f18bd0256157adb98306d53f8a52c.
Works great! I went with this template:
(add-to-list 'org-beamer-environments-extra
'("minipage" "m"
Envoyé de mon iPhone
> Le 16 juin 2015 à 13:46, Nicolas Goaziou a écrit :
>
> Rainer M Krug writes:
>
>> I would not remove it as even I have some org files using them - shame
>> on me.
>
> We can check for that in Org Lint and warn the user.
That would be a really good idea!
>
>> But wh
Envoyé de mon iPhone
> Le 16 juin 2015 à 14:45, Sebastien Vauban a écrit :
>
> Nicolas Goaziou writes:
>> Rainer M Krug writes:
>>
>>> I would not remove it as even I have some org files using them - shame
>>> on me.
>
> To be clear, are we talking of constructs such as:
>
> --8<-
Hi,
I encountered a strange problem today, exporting to beamer didn't
produce any pages eventhough it compiled just fine! It turns out it's
how Org exported the labels. They should be wrapped in {..}. See this
TeX.SX question for more: http://tex.stackexchange.com/q/250640/4416
The attached pa
Suvayu Ali writes:
> The attached patch should fix the issue.
Pushed, thanks. I changed the commit message slightly.
> * lisp/ox-beamer.el (org-beamer--get-label): wrap labels in {..}
You don't need the "lisp/" prefix. Capitalize after the colon. Should
end with period.
Rasmus
--
Slowly
On Mon, Apr 6, 2015 at 2:51 PM, Richard Lawrence <
richard.lawre...@berkeley.edu> wrote:
> Hi Aaron and all,
>
> Richard Lawrence writes:
>
> > Alright, I'll try to move to json.el, and possibly change to having
> > org-citeproc generate Org markup in the meantime.
>
> Just a heads up: I've pushe
Matt Price writes:
> Am just wondering what the current status is of the work that was being
> done earlier this year on improved citation support in org. Has an
> official syntax been settled on?
AFAIK: No. Some people wanted something like [cite/type: pre @key post].
Some people wanted addit
Hello,
Rasmus writes:
> Suvayu Ali writes:
>
>> The attached patch should fix the issue.
>
> Pushed, thanks. I changed the commit message slightly.
>
>> * lisp/ox-beamer.el (org-beamer--get-label): wrap labels in {..}
>
> You don't need the "lisp/" prefix. Capitalize after the colon. Should
On Jun 16, 2015 3:51 PM, "Rasmus" wrote:
>
> Matt Price writes:
>
> > Am just wondering what the current status is of the work that was being
> > done earlier this year on improved citation support in org. Has an
> > official syntax been settled on?
>
> AFAIK: No. Some people wanted something l
Nicolas Goaziou writes:
> Thanks. Nitpick however: wouldn't it be more readable to use "sec-" as
> a prefix instead of "sec:" in order to solve the issue?
I like "sec:", but the only package that actually relies on this, on the
top of my head, is autoref. I prefer {sec:whatever} over sec-whatev
Matt Price writes:
> Is the discussion stalled out then? What would have to happen to move it
> along?
Everybody got time constrains. Mine are binding severely at the moment
(not that I have contributed org-cite code).
I think it will be more of a priority after org 8.3.
--
The Kids call hi
Rasmus writes:
> I like "sec:", but the only package that actually relies on this, on the
> top of my head, is autoref. I prefer {sec:whatever} over
> sec-whatever.
OK. Let's keep it this way then. Thanks.
Regards,
Hello,
Matt Price writes:
> Is the discussion stalled out then? What would have to happen to move it
> along?
There is a "wip-cite" branch in the git repo with basic Org syntax for
citations. We're mainly waiting for implementations making use of it, on
both export and references management si
Hello.
Frequently, when I try to org-publish-project, I get a "Eager
macro-expansion failure"
The message buffer and backtrace are available here:
https://gist.github.com/julienchastang/98b268e9601882d8d81c
Indeed, I can simply reproduce this problem by calling
(load-with-code-conversion "/elp
Fabrice Popineau writes:
> Ideally, url encoded links should have been prefixed with some kind of uri
> syntax.
> This way, you could know what to decode and what not.
The encoded link could be copied from somewhere else. Also, there are
numerous links in the wild without this prefix.
> Now, I
Rainer M Krug writes:
>> We can check for that in Org Lint and warn the user.
>
> That would be a really good idea!
Done.
> Before deleting it, one should get a warning that a certain feature is
> deprecated. At the moment, it is only mentioned in the help (as far as
> I am aware).
It has been
Rainer M Krug writes:
> something along the line of "Link to non-existent local file "..." in
> the description part" would make clear that it is ion the description of
> a link.
Done. Thanks.
Regards,
On 16/06/15 11:49, Bob Newell wrote:
"Julian Burgos" writes:
b) I write the manuscript in org-mode. Then I send the org-mode file to
my coauthor. Because the org-mode file is just a text file, my coauthor
can use Word to edit it. I ask him/her *not* to use "track changes" and
to save the ed
Dear list,
I have been using org-ref for a while, using reftex to insert citations in
my org documents. Now I am switching to helm-bibtex, which is pretty
awesome. I have a couple of question about the note files. Org-ref uses
a single file to keep notes (e.g. notes.org), but helm-bibtex assume
Hello everyone,
I am view this file
http://doc.norang.ca/org-mode.org
It's a prettey long document, when it all folded up, navigating to previous
line and next line takes about 2 seconds. When the sub heading is shown,
it's more responsive. Is this a bug?
Thank you!
Yeah, helm bibtex is awesome. This has been a major topic of discussion in the
module development. See: https://github.com/tmalsburg/helm-bibtex/issues/40
Last I talked with the developer, he was thinking hard about it and had maybe
even started development on single-note file options.
"Julian
Julian Burgos writes:
> Dear list,
>
> I have been using org-ref for a while, using reftex to insert citations in
> my org documents. Now I am switching to helm-bibtex, which is pretty
> awesome. I have a couple of question about the note files. Org-ref uses
> a single file to keep notes (e.g.
On 2015-06-16 Tue 17:39, Julian Burgos wrote:
> Dear list,
>
> I have been using org-ref for a while, using reftex to insert citations in
> my org documents. Now I am switching to helm-bibtex, which is pretty
> awesome. I have a couple of question about the note files. Org-ref uses
> a single f
It slows everything, even change buffer takes about 2 seconds. And all this
slowness disappear when the buffer is unfolded.
Hi Nicolas, Fabrice,
On Tue, Jun 16, 2015 at 11:30:06PM +0200, Nicolas Goaziou wrote:
> Fabrice Popineau writes:
>
> > Ideally, url encoded links should have been prefixed with some kind of uri
> > syntax.
> > This way, you could know what to decode and what not.
>
> The encoded link could be c
On Tue, Jun 16, 2015 at 09:36:26PM +0200, Rasmus wrote:
> Suvayu Ali writes:
>
> > The attached patch should fix the issue.
>
> Pushed, thanks. I changed the commit message slightly.
>
> > * lisp/ox-beamer.el (org-beamer--get-label): wrap labels in {..}
>
> You don't need the "lisp/" prefix.
43 matches
Mail list logo
