Hello,
I have noticed a difficulty with :results table drawer babel blocks. It
isn’t possible to put ATTR_LATEX keywords on the table in that case. If
they are placed outside of the drawer, they apply to the drawer and not
the table. If they are placed inside it, they will be deleted when the
b
Hi again,
2013ko martxoak 19an, Aaron Ecay-ek idatzi zuen:
> I’m sorry, that was a mistake. I sent a patch to the HTML backend to
> enable this behavior, but forgot all about it. Then when I checked the
> code, it looked like the functionality was already there! I’ll follow
> up with Bastien ab
Hi Bastien,
2013ko martxoak 9an, Bastien-ek idatzi zuen:
>
> This is great -- I'll be offline this week-end, so I won't have time
> to have a careful look before monday. But I will.
I hope this is not bothersome, but have you had a chance to look at
these patches?
I thought they would solve t
Hi John,
2013ko martxoak 17an, John Hendy-ek idatzi zuen:
>
> #+begin_quote Aaron Ecay
>
> Eliminating subtleties is precisely the point of this change. All(-ish)*
> backends now use :width.
>
> * As far as I’ve checked, HTML(+ derived backends) and LaTeX(+derived
> backends). If there are an
Hi Eric,
I’m jointly replying to 2 of your emails.
2013ko martxoak 13an, Eric Schulte-ek idatzi zuen:
> This is what is already taking place. The :var header arguments are
> automatically expanded into dependencies between code blocks, and the
> results of previous code blocks are included in th
On 2/26/13, Nicolas Goaziou wrote:
> Try the following:
I got it to work. Thank you.
Samuel
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
The disease DOES progress. MANY people have died from it. ANYBODY
can get it. There is NO hope without action. This means YOU.
Hi Suvayu,
I’ve had on my list of rainy day ideas for a while writing a function
for org-export-filter-plain-text-functions that would implement
something like this. It should be as simple as doing a text replace,
either on “. [^ ]” sequences in general or only spaces after a given
list of abbrev
Hi Carsten,
Thank you for your very insightful thoughts. I would like to make one note.
2013ko martxoak 18an, Carsten Dominik-ek idatzi zuen:
> Now to the discussion with Z about additional emphasis definitions
> which he/she uses for custom highlighting of stuff. Right now this
> relies on mo
Thanks you all for the suggestions! Let me try out the suggestions and I
will report back on what worked.
Thanks again!
Shripad.
Shripad
Tucson, AZ
On Mon, Mar 18, 2013 at 6:07 PM, Thomas S. Dye wrote:
> Jay Kerns writes:
>
> > I don't know of a way to scale /within/ the code block, but does
Jay Kerns writes:
> I don't know of a way to scale /within/ the code block, but does
> this work instead?
>
#+NAME: foo
#+BEGIN_SRC R :session :exports results :results output org replace :tangle yes
cat("\\scriptsize")
print(list.files(recursive = T, pattern = "*.xls*"))
cat("\\normalsize")
#
shripad sinari writes:
> Hello all,
> Is there a way to scale the text in the latex export of a results
> block produced by a code chunk?
>
> Here is the code chunk i am trying to evaluate and export:
>
> #+BEGIN_SRC R :session :exports results :results output org replace :
> tangle yes
> print(l
Hello Shripad,
On Mon, Mar 18, 2013 at 7:44 PM, shripad sinari
wrote:
[snip]
> Is there a way for me to define the scaling of the text within the results
> block when this is exported using latex?
[snip]
I don't know of a way to scale /within/ the code block, but does
this work instead?
#+
Hello all,
Is there a way to scale the text in the latex export of a results block
produced by a code chunk?
Here is the code chunk i am trying to evaluate and export:
#+BEGIN_SRC R :session :exports results :results output org replace :tangle
yes
print(list.files(recursive = T, pattern = "*.xl
Hi Bastien,
thanks again for implementing this!
Bastien writes:
> Hi Andreas,
>
> Andreas Leha writes:
>
>> thanks for taking this up! But I am not sure, whether I like the
>> current implementation too much. Instead of saving the org-file itself,
>> I'd prefer the org-file to be auto-saved.
Carsten Dominik writes:
> The reason why the emphasis regexp components were made configurable
> in the first place is because when the feature was introduced, I had
> no idea what would work, and I redesigned this part several times
> over. Emphasis is a very heuristic system, the character tha
Hello all,
Andreas Leha wrote:
> t...@tsdye.com (Thomas S. Dye) writes:
>> Eric Schulte writes:
>>> Bastien writes:
"Sebastien Vauban" writes:
> As there was no reaction to this, I'd like to bump it up. At least, to
> either
> have a discussion on this, or a clearly stated
Subhan Tindall writes:
> Not quite - this wraps the headline visually, leaves any tags at the
> end, and doesn't fold the additional lines, as it technically leaves
> you with 1 long headline spanning multiple lines, not a 1-line
> headline with a body of text following it
I misread your request
Hi everyone,
first a disclaimer: Nicolas has thought about all things parser a lot more
than I have, so he might disagree. But here is my take on the issue.
First of all, we should not see Org as just another plain text markup language
(no offense meant, I am sure, and none taken). Because o
Not quite - this wraps the headline visually, leaves any tags at the
end, and doesn't fold the additional lines, as it technically leaves
you with 1 long headline spanning multiple lines, not a 1-line
headline with a body of text following it
On Fri, Mar 15, 2013 at 2:12 PM, Bastien wrote:
> Hi S
"Sebastien Vauban"
writes:
> Limitation: the effort is supposed to represent a big total or a daily amount
> (see property ":CLOCK_MODELINE_TOTAL: today"). Though, there is no such thing
> for a weekly limit.
If you set CLOCK_MODELINE_TOTAL to repeat you can use any interval you
like. Clock i
FWIW, the minibuffer behavior does not occur in NTEmacs.
GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-08-24 on YAMALOK
Dnia 2013-03-18, o godz. 14:40:24
Suvayu Ali napisał(a):
> Hi Orgers,
>
> I use double spaces to demarcate end of sentences
> (sentence-end-double-space t). Now when I use things like "e.g. " or
> "Fig. ", Emacs understands it is not the end of sentence and does the
> "right thing", say for fil
Dnia 2013-03-18, o godz. 15:21:54
wgreenho...@riseup.net (W. Greenhouse) napisał(a):
> Perhaps a compromise could be reached on variables such as
> `org-emphasis-alist' and others possibly slated for the defconst
> treatment: instead of doing that, let's consider keeping them
> customizable but in
zeltak writes:
> Dear Carsten,
>
> Thank you for your quick reply. Let me start by first thanking you
> for your great work on orgmode, I only recently discovered it
> (someone referred me to your great talk on youtube) and it made me
> have the courage to start learning emacs and use orgmode.
[
I don't if this is a bug or a feature however to me it's just
annoying. I've recently noticed that when moving up and down the agenda
some entries will cause the minibuffer to expand to two lines while
others make it shrink back to one. From bouncing around a bit, the one
thing in common I noticed
I've posted here before about it, but it looks like you're trying to do
the same thing as I am; see https://gitorious.org/org-diet
Here's an example of an org-diet file entry:
| Food / Exercise| Calories | Quantity | Total |
|+--
Hi Orgers,
I use double spaces to demarcate end of sentences
(sentence-end-double-space t). Now when I use things like "e.g. " or
"Fig. ", Emacs understands it is not the end of sentence and does the
"right thing", say for filling. However when I export a phrase like
that from Org, say to LaTeX,
Dear Carsten,
Thank you for your quick reply. Let me start by first thanking you for your
great work on orgmode, I only recently discovered it (someone referred me
to your great talk on youtube) and it made me have the courage to start
learning emacs and use orgmode.
I (actually me and several c
Achim Gratz writes:
> Eric Schulte writes:
>> I just pushed up a patch which should allow code blocks to find
>> un-named results even when there are comment lines (such as #+options
>> or #+attr_backend) between the code block and the results.
>
> Shouldn't babel use org-element for things like
Carsten Dominik writes:
> can you show an example on how you use it? Maybe we can find a better way.
> Nicolas is right that portability is compromised by customizable emphasis.
> On 18.3.2013, at 00:02, zeltak wrote:
>> I find the ability to add custom emphasise with custom faces invaluable.
Hi,
I'm trying to do some simple calculations, but the results are plain
wrong. I started the minimal example with `emacs -Q -l minimal.emacs
org/minimal.org'. My Emacs is 24.3 with Org-mode version 8.0-pre
(release_8.0-pre-116-g65cde8 @ /home/ov/p/org-mode/lisp/):
#+TITLE: Nutrition Facts
#+CO
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
-
Hi Z,
can you show an example on how you use it? Maybe we can find a better way.
Nicolas is right that portability is compromised by customizable emphasis.
- Carsten
On 18.3.2013, at 00:02, zeltak wrote:
> Hi all
>
> i just finished a great conversation on #org-mode with some great peopl
Hi List,
sometimes it make more sense to append a new value to a
multivalued-property than putting it in front of the old values, so here
is a patch that enables this:
>From ca1c5585fd7e57b559d360d3cbcc69b1deb18c98 Mon Sep 17 00:00:00 2001
From: tj
Date: Mon, 18 Mar 2013 10:40:54 +0100
Subject
t...@tsdye.com (Thomas S. Dye) writes:
> Eric Schulte writes:
>
>> Bastien writes:
>>
>>> Hi Sébastien,
>>>
>>> "Sebastien Vauban"
>>> writes:
>>>
As there was no reaction to this, I'd like to bump it up. At least, to
either
have a discussion on this, or a clearly stated "no go"
35 matches
Mail list logo
