Thanks, Eric.
-Original Message-
From: Eric Schulte [mailto:schulte.e...@gmail.com]
Sent: Thursday, February 28, 2013 9:29 PM
To: Richard Stanton
Cc: emacs-orgmode@gnu.org
Subject: Re: [O] Code blocks (partially) inherit buffer colors
Richard Stanton writes:
> When I export a code bloc
Richard Stanton writes:
> When I export a code block to HTML, I've noticed that some (but not
> all) of the characters in the resulting HTML file have the same
> background color as my Emacs buffer at the time I exported. For
> example, if I export
>
> ---
>
> #+begin_src python
> a = 5
>
When I export a code block to HTML, I've noticed that some (but not all) of the
characters in the resulting HTML file have the same background color as my
Emacs buffer at the time I exported. For example, if I export
---
#+begin_src python
a = 5
#+end_src
the code block i
Hi,
I wrote some code to fulfill the proposal you discussed two years ago, using
xclip and perl to yank image file in link format for org, and save the file
named after the image's timestamp.
Which means it's working for xwin clones, and I'm currently using Ubuntu 12.10.
The function is named
Gijs Hillenius writes:
Hi Gijs,
> Load the file spanish.org.
>
> load?
I've replaced it by "Open".
Thanks for reporting this.
--
Daimrod/Greg
pgpd4frI70f1U.pgp
Description: PGP signature
Hi Torsten,
> I gave calfw a new try yesterday. It works well now and I really like it!
> I tried to do, as you suggested, a export via htmlfontify-buffer.
> It seems like it has problems with the cell alignment for those cells which
> contain an
> appointment.
> Please see the attached picture
Being the noob that I am, it took me a few of my rare spare hours to
figure out what I was doing wrong with org-drill (sorry Paul!)
at:
http://orgmode.org/worg/org-contrib/org-drill.html
it says
Load the file spanish.org.
load?
m-x load-file /path/to/spanish.org will give (invalid-read-synta
Achim Gratz writes:
> Nicolas Goaziou gmail.com> writes:
>> I can write a document describing Org syntax, as seen by the parser, if
>> needed. It may serve as a first draft for an appendix in the Org manual.
>
> This would be very welcome. If you think I can be of help with any of this,
> pleas
Carsten Dominik writes:
> On 28.2.2013, at 13:30, Nicolas Goaziou wrote:
>
>> Carsten Dominik writes:
>>
>>> I agree, but I think then also setting the mark need to take care to
>>> set the mark in the base buffer. Will do this.
>>
>> AFAICT, this is not necessary. Indirect buffers share mark
Tom Regner goochesa.de> writes:
>
> I'd suggest: nowrap
>
> regards
> Tom
That inspires another idea: specifying :nowrap to turn off wrapping for the
block. Thus,
#+BEGIN_SRC emacs-lisp :nowrap
...
would not be wrapped, even if :wrap were set at a higher level.
[CC'ed to Takafumi Arakaki, author of orgparse]
Hello François,
> Do you know happen to know how conforming it is?
I can't comment on that, since I haven't really used it for anything.
> I wrote many ad hoc parsers for Org already, but what I would like
> is something really close to the parse
On 26 Feb 2013, Bastien wrote:
[...]
>> The second line made a bit of a mess of my .org files with the
>> 20130224 version of emacs-snapshot
>>
>> ;; (add-hook 'org-mode-hook 'turn-on-font-lock) ; org-mode buffers
>>only
>>
>> org files would still open, but show up as (imaginary example)
>
On 02/28/2013 09:59 AM, Samuel Wales wrote:
> The ellipses still occur.
>
> Here is an ECM.
>
> ===
> # -*- coding: utf-8 -*-
> #+CATEGORY: executive
>
> the long line and logbook are necessary. try with fewer
> lines and columns.
>
> * a
> *** a /a/ a a a a a a a a
Torsten Wagner writes:
> Hi Eric,
> thanks for the tip. I tried this already. Its printing but has some
> drawbacks. E.g. I use high resolution monitors in vertical (pivot) mode and
> a tiling window manager. calfw scales to the current buffer size and this
> is unfortunately not really compatibl
Bastien writes:
> Rainer M Krug writes:
>
>> I agree - COMMENTing a subtree should automatically disable tangling of code
>> blocks in the
>> subtree. Would this something which could be introduced easily, as it seems
>> there are quite a few
>> who assumed that it would be doing it?
>
> This
David Engster writes:
> You mean this cus-load thingie? CEDET is actually excluded from that, so
> we don't have to deal with it. But wouldn't it be enough to remove all
> properties beginning with 'org-' from custom-loads?
First you have to find all symbols, then remove the property and then
ther
Yagnesh Raghava Yakkala writes:
>> There is a need I often have, and never found the time to fill so far,
>> for a dependable Python parser for Org syntax.
> Not sure how complete it is [...] https://github.com/tkf/orgparse
Thanks for the pointer. With about 150 commits already, it seems th
Achim Gratz writes:
> David Engster writes:
>> An alternative would be to remove the bundled Org from load-path when a
>> newer version is loaded. We do that with CEDET, but it is difficult to
>> do right (because of autoloading, for instance), so I think the
>> eval-after-load hack is better.
>
>
On 28.2.2013, at 13:30, Nicolas Goaziou wrote:
> Carsten Dominik writes:
>
>> I agree, but I think then also setting the mark need to take care to
>> set the mark in the base buffer. Will do this.
>
> AFAICT, this is not necessary. Indirect buffers share markers with base
> buffer.
I think i
David Engster writes:
> An alternative would be to remove the bundled Org from load-path when a
> newer version is loaded. We do that with CEDET, but it is difficult to
> do right (because of autoloading, for instance), so I think the
> eval-after-load hack is better.
That part is actually relativ
On 2/28/13, Nicolas Goaziou wrote:
> Anyway, I've moved title out of inner template, which means it shouldn't
> appear anymore in body-only export.
Thank you.
Samuel
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
The disease DOES progress. MANY people have died from it. ANYBODY
The ellipses still occur.
Here is an ECM.
===
# -*- coding: utf-8 -*-
#+CATEGORY: executive
the long line and logbook are necessary. try with fewer
lines and columns.
* a
*** a /a/ a a a a a a a a a a
a a a a a a
:LOGBOOK:
- Not s
Hi Bastien,
On 2/20/13, Bastien wrote:
> Fixed, thanks!
Thank you. Not working though. Reverted?
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.
On Mar 01 2013, François Pinard wrote:
> Nicolas Goaziou writes:
>
>> I can write a document describing Org syntax, as seen by the parser [...]
>
> That would undoubtedly be useful.
>
> There is a need I often have, and never found the time to fill so far,
> for a dependable Python parser for O
Nicolas Goaziou writes:
> I can write a document describing Org syntax, as seen by the parser [...]
That would undoubtedly be useful.
There is a need I often have, and never found the time to fill so far,
for a dependable Python parser for Org syntax. I thought I could read
the Emacs Lisp code
Bastien writes:
> David Engster writes:
>
>> Of course I can fix this. But I hope you realize that any third-party
>> code out there that requires an exporter will load the old one from
>> Emacs proper.
>
> Yes, I'm well aware of this. The change now lives in the master
> branch, and will happen
Rasmus,
On Wed, Feb 27, 2013 at 01:13:25PM +0100, Rasmus wrote:
[...]
> In fact to use the scrlttr2 support in Org I had to adjust a LCO files
> because it's currently loaded after LATEX_HEADER arguments (so all
> customization was overwritten). I didn't like that.
After this remark I checked
Bastien,
Bastien wrote:
> "Sebastien Vauban" writes:
>> They should not visually disappear, but they do.
>
> No... chances are that it comes from your configuration. Please always
> assume it does first, then provide a recipe if it's with emacs -Q. Thanks!
Yes, it does. I still had the following
Sebastien Vauban wrote:
> Hello Frank and Nick,
>
> Nick Dokos wrote:
> > Frank Mueller wrote:
> >
> >> Just a remark to the Org-Mode Reference Card
> >> (http://orgmode.org/orgcard.pdf).
> >>
> >> There is a little bug in the spreadsheet description.
> >>
> >> wrong:
> >> sum from 2nd to 3rd
"Sebastien Vauban"
writes:
> Bastien wrote:
>> Rainer M Krug writes:
>>
>>> I agree - COMMENTing a subtree should automatically disable tangling of
>>> code blocks in the subtree. Would this something which could be introduced
>>> easily, as it seems there are quite a few who assumed that it w
"Sebastien Vauban"
writes:
> They should not visually disappear, but they do.
No... chances are that it comes from your configuration.
Please always assume it does first, then provide a recipe
if it's with emacs -Q. Thanks!
--
Bastien
Hallo,
I've been messing about with getting tables to display formula results
as for instance 30,00.00: two-place floating-point precision, and commas
grouping digits. I realize I can set these as the defaults in
org-calc-default-modes, but I wanted to alter the table formula format
string to allo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/02/13 10:47, Sebastien Vauban wrote:
> Hi Rainer,
>
> Rainer M Krug wrote:
>> On 28/02/13 10:30, Sebastien Vauban wrote:
>>> Bastien wrote:
Rainer M Krug writes:
> I agree - COMMENTing a subtree should automatically disable tangl
Carsten Dominik writes:
> I agree, but I think then also setting the mark need to take care to
> set the mark in the base buffer. Will do this.
AFAICT, this is not necessary. Indirect buffers share markers with base
buffer.
Regards,
--
Nicolas Goaziou
On 28.2.2013, at 11:22, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik writes:
>
>> OK, I pushed this change, maybe it is good if you have a brief look,
>> Nicolas.
>
> Thanks for the patch. It looks good. I have one minor suggestion,
> though. In the following snippet:
>
> (eq (marke
Using the org-mode included in Emacs HEAD as of yesterday, the following
content causes an error when exporting as html:
https://gist.github.com/purcell/5055957
Backtrace:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("\\([^]\\)\\([_^]\\)" nil)
org-export-p
As I learned the correct name for elisp to use with begin_src is emacs-lisp,
not elisp
On Feb 28, 2013, at 12:13 PM, Achim Gratz wrote:
> Karl Voit Karl-Voit.at> writes:
>> #+BEGIN_SRC elisp
>> (org-export-as-html 3 nil nil "htmlized-output" nil nil)
>> #+END_SRC
>
>> Am I doing something wro
Nicolas Goaziou gmail.com> writes:
> I can write a document describing Org syntax, as seen by the parser, if
> needed. It may serve as a first draft for an appendix in the Org manual.
This would be very welcome. If you think I can be of help with any of this,
please let me know.
Regards,
Achim
Karl Voit Karl-Voit.at> writes:
> #+BEGIN_SRC elisp
> (org-export-as-html 3 nil nil "htmlized-output" nil nil)
> #+END_SRC
> Am I doing something wrong or is this a bug?
You are trying to use the old exporter and pick up code from an earlier version
of Org.
Regards,
Achim.
Bastien writes:
> But be prepared for dealing with some stubbornness on my side:
> documenting the parser does not mean every issue should be solved
> thinking in terms of the parser. Sometimes there should be a
> tradeoff between what the parser can parse and what the UI should
> offer.
Obviou
Bastien altern.org> writes:
> Sorry to nitpick on this but please keep the Emacs-like change log
> small, if not terse.
I've thought about this, but then decided that the change does some seemingly
superfluous things and I'd better explain why they are necessary.
> Additionnal details are more
Mike Gauland schrieb:
>I've been using the :wrap parameter extensively, to give me control
>over the
>formatting of results from code blocks. For files with many such
>blocks, it
>makes sense to specify the formatting at the file level. This works
>well, unless
>I want a particular block to be
Hello,
Carsten Dominik writes:
> OK, I pushed this change, maybe it is good if you have a brief look,
> Nicolas.
Thanks for the patch. It looks good. I have one minor suggestion,
though. In the following snippet:
(eq (marker-buffer org-export-dispatch-last-position)
(curre
Hi Nicolas,
Nicolas Goaziou writes:
> I can write a document describing Org syntax, as seen by the parser, if
> needed. It may serve as a first draft for an appendix in the Org manual.
It will be useful in general; it will spare us miscommunication on
various aspects of the parser. So please f
Hi Rasmus,
Rasmus writes:
> Does this ONLY affect tangling or also other code?
Only tangling.
HTH,
--
Bastien
Andreas,
Andreas Leha wrote:
> Bastien writes:
>> You can subscribe to the RSS feed from
>> http://orgmode.org/cgit.cgi/org-mode.git/
>
> Sorry for hijacking this thread, and sorry for my ignorance. But where
> can I find this RSS feed?
You can find the group on Gmane (available, then, by NNTP
Hello,
Bastien writes:
> thanks for the thorough feedback.
>
> I reverted the change I made.
Thank you.
> I need to think more about the issue.
I can write a document describing Org syntax, as seen by the parser, if
needed. It may serve as a first draft for an appendix in the Org manual.
Bastien writes:> Rainer M Krug writes:
>
>> I agree - COMMENTing a subtree should automatically disable tangling of code
>> blocks in the
>> subtree. Would this something which could be introduced easily, as it seems
>> there are quite a few
>> who assumed that it would be doing it?
>
> This is
Hi Rainer,
Rainer M Krug wrote:
> On 28/02/13 10:30, Sebastien Vauban wrote:
>> Bastien wrote:
>>> Rainer M Krug writes:
>>>
I agree - COMMENTing a subtree should automatically disable tangling of
code blocks in the subtree. Would this something which could be
introduced easily, a
Hi Bastien,
Bastien writes:
[ ... ]
>
> You can subscribe to the RSS feed from
> http://orgmode.org/cgit.cgi/org-mode.git/
Sorry for hijacking this thread, and sorry for my ignorance. But where
can I find this RSS feed?
[ ... ]
Regards,
Andreas
Bastien,
Bastien wrote:
> Sebastien Vauban writes:
>
>> PS- Another question: some time ago, there was a ML with all the commits done
>> on Org. This seems to have disappeared (at least from Gmane). A reason for
>> that, or an alternative?
>
> I can't remember of such a mailing list.
>
> You can s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/02/13 10:30, Sebastien Vauban wrote:
> Bastien,
>
> Bastien wrote:
>> Rainer M Krug writes:
>>
>>> I agree - COMMENTing a subtree should automatically disable tangling of
>>> code blocks in the
>>> subtree. Would this something which could b
Bastien,
Bastien wrote:
> Rainer M Krug writes:
>
>> I agree - COMMENTing a subtree should automatically disable tangling of
>> code blocks in the subtree. Would this something which could be introduced
>> easily, as it seems there are quite a few who assumed that it would be
>> doing it?
>
> Thi
Hi Sébastien,
"Sebastien Vauban"
writes:
> I think the change of width can impact people who customize a bit the look of
> their agenda, and rely upong *all* the leaders to be of width 11. That was the
> motivation for my other patch, about clocking info (to make it go into a
> 11-char slot).
T
Bastien,
Bastien wrote:
> "Sebastien Vauban" writes:
>
>> Now, maybe you're hit by a feature here: when setting
>> `org-hide-emphasis-markers' to t, some `@' disappear from the formula (as
>> you see them, while they're there: enable visible-mode and check it!).
>
> Why would @ disappear with `org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/02/13 10:25, Bastien wrote:
> Rainer M Krug writes:
>
>> I agree - COMMENTing a subtree should automatically disable tangling of code
>> blocks in the
>> subtree. Would this something which could be introduced easily, as it seems
>> there ar
Rainer M Krug writes:
> I agree - COMMENTing a subtree should automatically disable tangling of code
> blocks in the
> subtree. Would this something which could be introduced easily, as it seems
> there are quite a few
> who assumed that it would be doing it?
This is now the case in master:
ht
Bastien,
Bastien wrote:
> "Sebastien Vauban" writes:
>
>> Though, one question: why did you change the spacing (and, in fact, the
>> width)
>> of the leaders?
>>
>> -(defcustom org-agenda-scheduled-leaders '("Scheduled: " "Sched.%2dx: ")
>> +(defcustom org-agenda-scheduled-leaders '(" Scheduled:
On 28.2.2013, at 09:39, Carsten Dominik wrote:
>
> On 27.2.2013, at 16:22, Nicolas Goaziou wrote:
>
>> Carsten Dominik writes:
>>
>>> OK, I see that this is a bit less trivial then I thought, requires
>>> that I study the ui interface a bit more.
>>
>> I think the only pieces of the UI in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/02/13 00:33, Darlan Cavalcante Moreira wrote:
>
> I also converted my Emacs configuration to an org-mode file a long time ago
> and I hit the same
> spot you did. As you, I initially assumed (wished) that the COMMENT marker
> would disable
> t
Hi Achim,
Achim Gratz writes:
> * lisp/ob-core.el (org-babel-execute-src-block): Do not ask for
> confirmation if the cached result is current. Since
> `org-babel-confirm-evaluate´ does additional things besides asking
> for confirmation, call it first with `org-confirm-babel-evaluate´
>
Hi Nicolas,
thanks for the thorough feedback.
I reverted the change I made.
I need to think more about the issue.
Best,
--
Bastien
Hi Sébastien,
"Sebastien Vauban"
writes:
> Now, maybe you're hit by a feature here: when setting
> `org-hide-emphasis-markers' to t, some `@' disappear from the formula (as you
> see them, while they're there: enable visible-mode and check it!).
Why would @ disappear with `org-hide-emphasis-mar
Hello Frank and Nick,
Nick Dokos wrote:
> Frank Mueller wrote:
>
>> Just a remark to the Org-Mode Reference Card
>> (http://orgmode.org/orgcard.pdf).
>>
>> There is a little bug in the spreadsheet description.
>>
>> wrong:
>> sum from 2nd to 3rd hline |:=vsum(@II..@III)|
>>
>> correct:
>> sum
Hi Sébastien,
"Sebastien Vauban"
writes:
> PS- Another question: some time ago, there was a ML with all the commits done
> on Org. This seems to have disappeared (at least from Gmane). A reason for
> that, or an alternative?
I can't remember of such a mailing list.
You can subscribe to the RSS
I've been using the :wrap parameter extensively, to give me control over the
formatting of results from code blocks. For files with many such blocks, it
makes sense to specify the formatting at the file level. This works well, unless
I want a particular block to be unwrapped. Just specifying :wrap
On 27.2.2013, at 16:22, Nicolas Goaziou wrote:
> Carsten Dominik writes:
>
>> OK, I see that this is a bit less trivial then I thought, requires
>> that I study the ui interface a bit more.
>
> I think the only pieces of the UI involved are `org-export-dispatch'
> function and `org-export-di
Hi Sébastien,
"Sebastien Vauban"
writes:
> Though, one question: why did you change the spacing (and, in fact, the width)
> of the leaders?
>
> -(defcustom org-agenda-scheduled-leaders '("Scheduled: " "Sched.%2dx: ")
> +(defcustom org-agenda-scheduled-leaders '(" Scheduled: " "Sched.%3dx: ")
>
Hi Aaron,
Aaron Ecay wrote:
> 2013ko otsailak 27an, Sebastien Vauban-ek idatzi zuen:
>>
>> Do you know if there was a way out -- other than killing Emacs -- in such a
>> case where `C-g' is not working?
>
> If you are on Linux (or OS X, I suppose), you can sometimes break an
> infloop by sending
Hi Bastien,
Bastien wrote:
> Hi Sébastien,
>
> Bastien writes:
>
>>> Here's a patch to allow for a different prefix for deadline entries which
>>> are
>>> in the past: for example, "3 d ago" instead of "In -3 d"...
>>
>> Please make sure the change is backward compatible so that users don't
>> h
70 matches
Mail list logo
