date:20100810

* org-read-prop
** added a more detailed comment
** changed 2 if stements to 1 cond to make the code more comprehensible.
** added 
(condition-case nil
(read prop)
(error prop)))

instead of
(read prop)

so, if any error occurs during the conversion of prop to lisp expression - a 
string will be returned.

** The scheme of the new function if attached.

org-collector.el.diff
Description: Binary data


org-collector.pdf
Description: Adobe PDF document
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] why not auto-renumbering list ?

2010-08-10 Thread Andrew Swann


On 10/8/10 11:46 , "Nicolas Goaziou"  wrote:

> Hello,
> 
>> Andrew Swann writes:
> 
>> I have a related but slightly off topic question that arose when setting up
>> org versions of Danish course homepages.  How do I get something like
> 
>> 2. kvartal
> 
>> (meaning 2nd quarter) on a line on its own that is *not* treated as a list
>> (and thus renumbered on publication) ?
> 
> You can set `org-plain-list-ordered-item-terminator' to ?). Thus, only
> ordered lists with a parenthesis are allowed, and your line will not
> be treated as a list item anymore.

Many thanks for this suggestion.  It is certainly useful.  Is there a local
solution that could be used just around this line?  It would be nice if one
could escape the period.

Andrew

-- 
Andrew Swann sw...@imada.sdu.dk http://www.imada.sdu.dk/~swann
Department of Mathematics and Computer Science,  Tel +45 6550 2354
and CP3-Origins, University of Southern Denmark,Dept +45 6550 2387
Campusvej 55, DK-5230 Odense M, Denmark  Fax +45 6550 2325


___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] why not auto-renumbering list ?

2010-08-10 Thread Nicolas Goaziou

> Andrew Swann writes:

> Many thanks for this suggestion.  It is certainly useful.  Is there a local
> solution that could be used just around this line?  It would be nice if one
> could escape the period.

Enforce numbering to 2 with [...@start:2]. It will still be treated as a
list, but it won't be renumbered.

Otherwise, if this isn't at column 0, you can insert a non-breaking
space (C-q 240) somewhere in front of your item. Org will not
recognize a list, and it will be invisible when exporting.

HTH,

-- Nicolas

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re[2]: need detailed instructions for submitting the patch

Carsten, can you kindly add this to 
http://orgmode.org/worg/org-contribute.php#sec-3

"
To submit the patch follow the instructions:

This command will make a patch between the staging area
(in your computer), and the file you modified:

git diff -p org-whatever.el > org-whatever.el.diff

If you already committed your changes to your index (staging area),
then you should compare against a particular branch (in this example,
origin/master):

git diff -p origin/master org-whatever.el > org-whatever.el.diff

You email the output to the mailing list, adding [PATCH] to the
subject, and description of what you fixed or changed.
"

Should I add  "> org-whatever.el.diff" to output the diff into a file, cause in 
Juans message it was missing?

It will be helpful to the new developers, I think.


___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] text color + highlight

Hi Christian,

Christian Moe  writes:

> Hi,
>
> I'm sorry my point was buried in quoted text. I did read Samuel's
> post. But my question was whether we couldn't *avoid inventing new
> syntaxes*, by using the already existing link syntax with custom links
> and export handlers (plus possibly some some new functionality to
> user-customize the faces of different link types in Org-mode).
>
> e.g.
>
> : [[color:red][some text in red]]
> : [[class:highlight][some highlighted text]]
>
>
> It's already trivial to write one's own `color' and `class' custom
> link types with export handlers to turn this into HTML such as:
>
> : some text in red
> : some highlighted text
>

Thanks for making this suggestion.  This is a much better solution than
creating a new syntax out of whole cloth, I should have known that Org
would already have a working solution in place.

Just for completeness I'm adding an example of a color handler which can
be added to a users config to enable colorization of exported text to
html and latex.

--8<---cut here---start->8---
(org-add-link-type
 "color" nil
 (lambda (path desc format)
   (cond
((eq format 'html)
 (format "%s" path desc))
((eq format 'latex)
 (format "{\\color{%s}%s}" path desc)
--8<---cut here---end--->8---

it should be fairly straightforward to extend the above for background
or class link types

>
> (where the latter example would be styled by CSS).
>
> Doing this in exported text requires *no changes* to Org-mode. It also
> does not require finding one solution that fits everybody.
>
> If one wants Org text styled in these colors, highlights etc., I
> suppose it would require changes in Org-mode: not just
> user-customizable faces for different link types, as I wrote in the
> previous message, but a function to define link faces on the fly from
> the PATH part of the link.
>

I think in-buffer colorization is much less important than the export
behavior.

Cheers -- Eric

>
>
> Christian
>
> Carsten Dominik wrote:
>> Hi,
>>
>> Can we please first read Samuels post about extensible syntax?
>> Before we invent 20 other new syntaxes?
>>
>> http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10204
>>
>> Thanks!
>>
>> On Aug 10, 2010, at 8:14 AM, Christian Moe wrote:
>>
>>> Hi,
>>>
>>> >>
>>> >> - this would be extensible, e.g.
>>> >>
>>> >>  [background[yellow] highlighted text]
>>> >>
>>> >>  could export to the following html
>>> >>
>>> >>  highlighted text
>>> >>
>>> >> - this would avoid "{}"s
>>> >>
>>> >> - this would look more "org-like" than the pure latex solution
>>> >>
>>> >> the only issue with the above is that it may conflate a new /markup/
>>> >> syntax with org-mode's existing /link/ syntax.
>>> >>
>>> >> Thoughts? -- Eric
>>>
>>> I'd like an extensible inline markup construct (not primarily for
>>> coloring).
>>>
>>> Would it make sense to hijack custom links for this purpose, and
>>> use existing bracketed link syntax rather than add a new syntax?
>>>
>>> For semantic tagging (my chief interest), one might e.g. define a
>>> class' link type and an HTML export handler to wrap the contents in
>>>  tags.
>>>
>>> : [[class:animals][some text about animals]]
>>>
>>> As for color: If one is satisfied with getting colors on export,
>>> defining a `color' link type and appropriate export handlers will
>>> do.
>>>
>>> : [[color:red][some colored text]]
>>>
>>> If one also wants the text to appear in the right color within
>>> Org-mode, and does not want the pseudo-link markup to be underlined
>>> and look like links, it would require additional Org functionality
>>> (I think): User-defined custom faces for different link types.
>>>
>> What syntax to use...
>
> I've thought briefly about the following syntax
>
> [color[red] text to be colored red]
 Nope, I am against this syntax.  If we introduce a more general syntax,
 then it should be done in the way Samuel proposed.  WHich means
 we firs get a keyword indtroducing the piece, and then properties.
 Like
   $[style :color red the red text]
 or
   $[face :color :italic t red the red text]
 Something like the $ before "[" also would seem critical to disambiguate
 from other uses of "[".
 However, I am not too excited about extra syntax to get this kind
 of thing.
 Would not oppose it, but probably never use it.
 - Carsten
>>>
>>> Those examples are not very readable IMO -- without a separator
>>> it's hard to see where the property values end and the marked up
>>> text begins.
>>>
>>> Yours,
>>> Christian
>>
>> - Carsten
>>
>>
>>
>>
>> ___
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>

___
Emacs-orgmode mailing list
Please use `Reply All' to send r

Re: [Orgmode] [PATCH] /contrib/lisp/org-collector.el

Hi,

This patch has been applied with some very minor indentation and
whitespace changes.

Thanks for the patch and the elucidation of the comments and code.

Best -- Eric

Ivanov Dmitry  writes:

> * org-read-prop
> ** added a more detailed comment
> ** changed 2 if stements to 1 cond to make the code more comprehensible.
> ** added 
> (condition-case nil
>   (read prop)
>   (error prop)))
>
> instead of
> (read prop)
>
> so, if any error occurs during the conversion of prop to lisp expression - a 
> string will be returned.
>
> ** The scheme of the new function if attached.
>
>
> ___
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re[2]: need detailed instructions for submitting the patch

2010-08-10 Thread Bastien

Ivanov Dmitry  writes:

> Carsten, can you kindly add this to
> http://orgmode.org/worg/org-contribute.php#sec-3

Ivanov, please register at http://repo.or.cz and drop me an email with
your username -- then you'll be able to improve this page.

Please reread Bernt's email before doing so, it might help keeping
things clear.

Thanks!

-- 
 Bastien

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re[2]: need detailed instructions for submitting the patch

Added. Thanks -- Eric

Ivanov Dmitry  writes:

> Carsten, can you kindly add this to 
> http://orgmode.org/worg/org-contribute.php#sec-3
>
> "
> To submit the patch follow the instructions:
>
> This command will make a patch between the staging area
> (in your computer), and the file you modified:
>
> git diff -p org-whatever.el > org-whatever.el.diff
>
> If you already committed your changes to your index (staging area),
> then you should compare against a particular branch (in this example,
> origin/master):
>
> git diff -p origin/master org-whatever.el > org-whatever.el.diff
>
> You email the output to the mailing list, adding [PATCH] to the
> subject, and description of what you fixed or changed.
> "
>
> Should I add  "> org-whatever.el.diff" to output the diff into a file, cause 
> in Juans message it was missing?
>
> It will be helpful to the new developers, I think.
>
>
> ___
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] What license for Worg?

2010-08-10 Thread Bastien

David Maus  writes:

> IIRC there was some back and forth about compatibility of this
> statement and the GPL, but cannot remember where I read this.  This is
> obvious, but why not just drop a message to FSF legal team with the
> question about this issue?

I'm in touch with RMS about this issue.  Will follow-up on the list very
soon.

-- 
 Bastien

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Email from org?

Hi Ethan,

Ethan Ligon  writes:

> Eric Schulte  gmail.com> writes:
>> The following function might get part way towards what you describe.
>> 
>> --8<---cut here---start->8---
>> (defun org-send-email-of-headline ()
>>   (interactive)
>>   (let ((subject (org-get-heading t))
>> (to (org-entry-get (point) "mailto")))
>> (outline-mark-subtree)
>> (org-mime-org-buffer-htmlize)
>> (save-excursion
>>   (message-goto-to) (insert to)
>>   (message-goto-subject) (insert subject
>> --8<---cut here---end--->8---
>> 
>
> Indeed!  This gets me very close to what I had in mind.  Aside from
> saying thanks, I have two related things to say:
>
> 1) The code snippet above (really org-mime-org-buffer-htmlize)
> produces output which is either designed to be further processed by
> the mml library (mml-generate-mime) for gnus users or by the semi
> library for wanderlust users.  Thus, the buffer resulting from the
> above code-snippet is still one step away from being something one
> could feed to smtpmail, and makes the output one needs to get from
> org-mime dependent on an MUA (gnus or wanderlust).
>

I personally like this final step of review before sending an email.

As for requiring that the user has an mailer with which to send the
email, it would be possible to change `org-mime-org-buffer-htmlize' to
use `reporter-submit-bug-report' to send the email directly instead of
using `reporter-compose-outgoing' which only prepares the email buffer.

I'm not sure of how to do this while still allowing the existing
behavior for those who do use Emacs for email.  Also, I find the idea of
having a key command send an email from an Org-mode buffer without any
form of confirmation terrifying. :)

>
> 2) I don't see the reason for this dependence.  Forget what mail
> client the user prefers, whether gnus or wanderlust or something else.
> Why not just feed the output of org-mime to a scratch buffer, run
> (mml-generate-mime) on that, stick the output in a message buffer,
> build a header, and then run smtpmail-send-it?  
>

for example, I sometimes like to add a Gcc: header argument to an
outgoing email so that a copy is saved in one of my mail groups.

>
> 3) Okay, I see one reason for the dependence: I guess that mml isn't
> part of the base emacs distribution.  
>

Yes, I suppose mml is part of gnus, but as gnus is distributed along
with Emacs this may be something whose availability can be assumed.

>
> 4) And I see another reason: if one wanted to edit the htmlized buffer
> it might be a little more convenient to work with the semi or mml
> representations instead of the mime.  
>

yes

>
> But (3) and (4) seem weak to me.  What am I missing?
>

My biggest motivation is presented after (1) above.

Best -- Eric

>
> -Ethan
>
>
>
>
>
> ___
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: How to get pretty printed source code in PDFLaTeX

2010-08-10 Thread Thomas S. Dye

Hi Dan,

One of the design goals of LaTeX is to use semantic markup in the
source and to keep details of representation separate, typically in a
style or class file that is used to render the semantic markup. From
this perspective, the cleanest implementation would be to create a
LaTeX style or class file for use with org-mode, where the gory
details of listings vs. minted, etc. could be worked out. This would
leave org-mode to do what it does very well, which is to identify and
mark the relevant semantic units, and would at the same time simplify
org-mode configuration.

For the user, this would require the org-mode.sty or org-mode.cls file
be placed somewhere LaTeX could find it and creating an export target
for it in .emacs.

This might not qualify as "out of the box" but the looser coupling
between org-mode and LaTeX is likely to be a plus in the long run.

All the best,
Tom

On Aug 9, 2010, at 12:29 PM, Dan Davison wrote:

Sébastien Vauban +fvcfc7...@public.gmane.org>

writes:

Hi Dan,

Dan Davison wrote:
Sébastien Vauban > writes:

Sebastian Rose wrote:
Dan Davison
writes:
Can you point me to an example that shows how to make source
code in

latex look (almost) as nice as html?

That is supposed to work with the `listings' package. I havent
tried that

yet.

If I understand you right, here's such an example you're after:

* Much better code

[...]

I've put the PDF (for easy access) onto my Web site:

http://www.mygooglest.com/sva/ECM-Listings.pdf

Wow, that's really nice. Thanks for sharing that.

I really thought that you used such a thing for a long time, having
done so
much for Org-Babel. Maybe you were more interested by the execution
stuff,
rather than its printing? For me, the opposite: I was much
interested by the

printing, now by accessing all the power of Babel.

You're probably right that I should have looked into it. But seeing as
the HTML export of code is so nice and requred no configuration, I
never

got round to it. Although I did write my Ph.D. in latex, and I am
enjoying using the listings package for formatting pseudocode in a
paper

which I'm supposed to be writing, I do need to become better friends
with latex, it's true.

I think we should aim to get to a point where org-mode can produce
such

nicely formatted source code out-of-the-box.

I share your point. I'm willing to participate, or even begin, such
a page on

Worg, with the above info.

Maybe we could even make latex inherit the colours and fonts that
emacs is

currently using for source code mark up?

For sure, that'd be nice. You mean the way htmlize works, and keeps
my colors,

right?

Dunno what it implies for Org-LaTeX... Generating your own class
customization,

and having it loaded by default (in the list of LaTeX packages)?

Usage of listings is controlled by the variable
`org-export-latex-listings', so the simplest start would be: if that
is

non-nil then code like yours could be inserted into the latex output.

I was going to suggest doing this with listings but then came
across minted,
and I wonder whether that's even more suitable? (See the other
post I just

made.)

Never heard about it before, while I'm trying to follow info about
TeX as

well.

I'm very impressed by the quality and reaction time of
french.computers.text.tex. So, I decided to ask them what they
thought about

Listings vs Minted.

,
| "sur un post de Dan Davison parlant d'un nouveau paquet qui
| serait mieux que Listings."
`

Hey, I never said that! :)

I said it might be better *for export of code from org-mode*. But
seriously, no problem, in addition to my character assassination, from
what I could make out they made lots of good points. Although I will
watch out now if I come across any francophones who look like they
might

be tex enthusiasts (wouldn't one always...)

What I meant is that seeing as org-users who set
`org-export-latex-listings' get black and white code with ugly fonts
by

default, there are two improvement options for us:

1. we work on incorporating nice listings configuration into org
mode so

that Org users get nice colours and fonts by default
2. we add an option to allow Org users to use the minted package,
which

gives them nice colours and fonts automatically.

(2) was easy and so I did it straight away. And (1) is still something
we want to do, not least because listings is in standard latex
distributions and doesn't have an extra python requirement. Assuming
that minted/pygments are stable software that will be around for a
while, I would vote for both options ultimately being available in
org-mode.

See on [[http://groups.google.com/groups/search?as_umsgid%3D87lj8gp4rr.fsf%40mundaneum.com
][Email from Sébastien Vauban: Listings vs Minted]]

What's interesting is that 2 brilliant people of that list
responded on that.

I could try to translate the whole, but there already is a lot. Just
highlighting that t

Re[2]: [Orgmode] Re[2]: need detailed instructions for submitting the patch

> Ivanov, please register at http://repo.or.cz and drop me an email with
> your username -- then you'll be able to improve this page.


My username is usr345


> Please reread Bernt's email before doing so, it might help keeping
> things clear.

I was trying to understand, how to create a topic branch from Bernts email, but 
I couldn't. I understood only one:

1. Put the email into .git/config

| [sendemail]
|   to = emacs-orgmode@gnu.org

For example, I have a modified file org-whatever.el. What commands must I run?


___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: How to get pretty printed source code in PDFLaTeX

"Thomas S. Dye"  writes:

> Hi Dan,
>
> One of the design goals of LaTeX is to use semantic markup in the
> source and to keep details of representation separate, typically in a
> style or class file that is used to render the semantic markup.  From
> this perspective, the cleanest implementation would be to create a
> LaTeX style or class file for use with org-mode, where the gory
> details of listings vs. minted, etc.

Yes, although may I repeat that in the case of minted there are no gory
details. The patch I submitted already works to give org users
out-of-the-box pretty fontified code with nothing more required than
installation of pygments and putting minted.sty in a suitable
place. Pending the work on listings that you and Seb and I are
proposing, the minted patch is therefore a useful advance for org
mode. It can always be removed later if it becomes clear that it is
completely redundant in view of newly improved org/listings support.

But yes, absolutely, what you say is definitely helpful for those
planning work on improving listings support.

Dan

> could be worked out.  This would
> leave org-mode to do what it does very well, which is to identify and
> mark the relevant semantic units, and would at the same time simplify
> org-mode configuration.
>
> For the user, this would require the org-mode.sty or org-mode.cls file
> be placed somewhere LaTeX could find it and creating an export target
> for it in .emacs.
>
> This might not qualify as "out of the box" but the looser coupling
> between org-mode and LaTeX is likely to be a plus in the long run.
>
> All the best,
> Tom
>
> On Aug 9, 2010, at 12:29 PM, Dan Davison wrote:
>
>>
>>
>> Sébastien Vauban > +fvcfc7...@public.gmane.org>
>> writes:
>>
>>> Hi Dan,
>>>
>>> Dan Davison wrote:
 Sébastien Vauban
 >>> > writes:
> Sebastian Rose wrote:
>> Dan Davison 
>> writes:
>>> Can you point me to an example that shows how to make source
>>> code in
>>> latex look (almost) as nice as html?
>>
>> That is supposed to work with the `listings' package. I havent
>> tried that
>> yet.
>
> If I understand you right, here's such an example you're after:
>
> * Much better code
>>
>> [...]
>>
> I've put the PDF (for easy access) onto my Web site:
>
> http://www.mygooglest.com/sva/ECM-Listings.pdf

 Wow, that's really nice. Thanks for sharing that.
>>>
>>> I really thought that you used such a thing for a long time, having
>>> done so
>>> much for Org-Babel. Maybe you were more interested by the execution
>>> stuff,
>>> rather than its printing? For me, the opposite: I was much
>>> interested by the
>>> printing, now by accessing all the power of Babel.
>>
>> You're probably right that I should have looked into it. But seeing as
>> the HTML export of code is so nice and requred no configuration, I
>> never
>> got round to it. Although I did write my Ph.D. in latex, and I am
>> enjoying using the listings package for formatting pseudocode in a
>> paper
>> which I'm supposed to be writing, I do need to become better friends
>> with latex, it's true.
>>
 I think we should aim to get to a point where org-mode can produce
 such
 nicely formatted source code out-of-the-box.
>>>
>>> I share your point. I'm willing to participate, or even begin, such
>>> a page on
>>> Worg, with the above info.
>>>
 Maybe we could even make latex inherit the colours and fonts that
 emacs is
 currently using for source code mark up?
>>>
>>> For sure, that'd be nice. You mean the way htmlize works, and keeps
>>> my colors,
>>> right?
>>>
>>> Dunno what it implies for Org-LaTeX... Generating your own class
>>> customization,
>>> and having it loaded by default (in the list of LaTeX packages)?
>>
>> Usage of listings is controlled by the variable
>> `org-export-latex-listings', so the simplest start would be: if that
>> is
>> non-nil then code like yours could be inserted into the latex output.
>>
>>>
 I was going to suggest doing this with listings but then came
 across minted,
 and I wonder whether that's even more suitable? (See the other
 post I just
 made.)
>>>
>>> Never heard about it before, while I'm trying to follow info about
>>> TeX as
>>> well.
>>>
>>> I'm very impressed by the quality and reaction time of
>>> french.computers.text.tex. So, I decided to ask them what they
>>> thought about
>>> Listings vs Minted.
>>
>> ,
>> | "sur un post de Dan Davison parlant d'un nouveau paquet qui
>> | serait mieux que Listings."
>> `
>>
>> Hey, I never said that! :)
>>
>> I said it might be better *for export of code from org-mode*. But
>> seriously, no problem, in addition to my character assassination, from
>> what I could make out they made lots of good points. Although I will
>> watch out now if I come across any francophones who look like they
>> might
>> be tex enthusiasts (wouldn't one always...)
>>
>> What I meant is that seeing as org-users who set
>

Re: [Orgmode] Re[2]: need detailed instructions for submitting the patch

2010-08-10 Thread Bastien

Hi Ivanov,

Ivanov Dmitry  writes:

>> Ivanov, please register at http://repo.or.cz and drop me an email with
>> your username -- then you'll be able to improve this page.
>
> My username is usr345

Thanks - I added you, you can now push changes to Worg.

> 1. Put the email into .git/config
>
> | [sendemail]
> |   to = emacs-orgmode@gnu.org

Caution: this is for Org-mode changes, not Worg.  There is no mailing
list for Worg, please don't use this setting in your Worg/.git/config

You might use

,
| [sendemail]
|   to = b...@gnu.org
`

in ~/install/git/Worg/.git/config (or the proper location) to send me
Worg patches directly, but since you have push access now there is no
real need for this.

> For example, I have a modified file org-whatever.el. What commands
> must I run?

Please follow the instructions on Worg and let us know what is not
crystal-clear -- that will help improve the doc if necessary.

HTH,

-- 
 Bastien

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re[2]: need detailed instructions for submitting the patch

2010-08-10 Thread Nick Dokos

Bastien  wrote:

> > For example, I have a modified file org-whatever.el. What commands
> > must I run?
> 
> Please follow the instructions on Worg and let us know what is not
> crystal-clear -- that will help improve the doc if necessary.
> 

I think Dmitry is asking for the git commands and I'm not sure those
are described anywhere on Worg.

Something like this perhaps:

 # create a topic branch to deal with a specific topic: use
 # a descriptive name!
 git checkout -b topic-branch-foo master

 git commit -a
 git format-patch

Then when the patch hits mainline (or it is irrevocably rejected), get
rid of the branch:

 git branch -D topic-branch

Nick

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: need detailed instructions for submitting the patch

Nick Dokos  writes:

> Bastien  wrote:
>
>
>> > For example, I have a modified file org-whatever.el. What commands
>> > must I run?
>> 
>> Please follow the instructions on Worg and let us know what is not
>> crystal-clear -- that will help improve the doc if necessary.
>> 
>
> I think Dmitry is asking for the git commands and I'm not sure those
> are described anywhere on Worg.
>
> Something like this perhaps:
>
>  # create a topic branch to deal with a specific topic: use
>  # a descriptive name!
>  git checkout -b topic-branch-foo master
>  
>  git commit -a
>  git format-patch
>  

One point I'm not yet clear on:

For the patchwork system, what methods of inclusion of patch in email
are acceptable?

+ attachment type text/plain?
+ attachment type text/x-diff?
+ attach using C-c C-a in gnus but choose "inline" rather than as
  "attachment"?
+ paste inline?
+ paste inline with special gnus separators --8<-- ?

does it matter how the patch file is named?

Also, what requirements are there on how to *reply* so that your message
gets lumped by patchwork into the same patch item, rather than creating
a new item? Can the subject line be modified?

Dan

>  
> Then when the patch hits mainline (or it is irrevocably rejected), get
> rid of the branch:
>
>  git branch -D topic-branch
>
> Nick
>
> ___
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re[2]: [Orgmode] Re[2]: need detailed instructions for submitting the patch

Yes, Nick, I was asking about the git commands. Thanks. It seems, that creating 
a topic branch is more complicated, then simply editing the local master copy, 
creating a diff file and sending it to the mailing list. I think it should be 
used only in complicated cases.

Dmitry


___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re[2]: [Orgmode] Re[2]: need detailed instructions for submitting the patch

2010-08-10 Thread Nick Dokos

Ivanov Dmitry  wrote:

> Yes, Nick, I was asking about the git commands. Thanks. It seems, that
> creating a topic branch is more complicated, then simply editing the
> local master copy, creating a diff file and sending it to the mailing
> list. I think it should be used only in complicated cases.
> 

I prefer to keep a pristine master branch and create lots of topics branches,
(most of which die a quick and merciful death.) It's not really hard to create
a branch and it keeps things *much* neater, so I would recommend that approach
even for simple changes.

Nick

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re[2]: [Orgmode] Re[2]: need detailed instructions for submitting the patch

2010-08-10 Thread Thomas S. Dye


Aloha Dmitry,

Another reason for working in topic branches is it leaves your master  
branch clean so that changes in the remote are easily merged.  You're  
are probably more computer savvy than I am, but my struggles with  
merges after making changes to the master branch have been trying.  I  
try to leave master clean at all times now.


All the best,
Tom

On Aug 10, 2010, at 8:14 AM, Ivanov Dmitry wrote:

Yes, Nick, I was asking about the git commands. Thanks. It seems,  
that creating a topic branch is more complicated, then simply  
editing the local master copy, creating a diff file and sending it  
to the mailing list. I think it should be used only in complicated  
cases.


Dmitry


___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode



___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Tip: How to copy&paste a table from Firefox to Org

Hi all,

posting in case this is useful to someone else:

I just figured out how to copy & paste tabular data from Firefox to an
Org buffer (in my case: a train schedule from www.bahn.de).

- Select data in Firefox
- Paste into Org, select it as the region
- M-x replace-regexp  C-i \ | ^  | 

  C-i inserts a tab character (you can also use C-q  instead).
  We replace each beginning of a line and each tab character with "|".

- Place the cursor on the table and press C-c C-c to align it

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] text color + highlight

2010-08-10 Thread Christian Moe


Hi, Eric,

Thanks for trying this out -- I should have taken the trouble to write 
out sample code myself.



Just for completeness I'm adding an example of a color handler which can
be added to a users config to enable colorization of exported text to
html and latex.

--8<---cut here---start->8---
(org-add-link-type
 "color" nil
 (lambda (path desc format)
   (cond
((eq format 'html)
 (format "%s" path desc))
((eq format 'latex)
 (format "{\\color{%s}%s}" path desc)
--8<---cut here---end--->8---



A drawback with using links for markup is that the user sees things that 
look like links, but do nothing when clicked, except give error messages.


So instead of setting the third argument -- the "follow" function -- to 
nil, I'd flash the user an informative message, e.g.


--8<---cut here---start->8---
(org-add-link-type
 "color"
 (lambda (path)
   (message
(format "This link adds %s color but goes nowhere" path)))
 (lambda (path desc format)
   (cond
((eq format 'html)
 (format "%s" path desc))
((eq format 'latex)
 (format "{\\color{%s}%s}" path desc)
--8<---cut here---end--->8---


Yours,
Christian

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: How to get pretty printed source code in PDFLaTeX

2010-08-10 Thread Thomas S. Dye


Hi Dan,

Yes, sorry, "gory" was off the mark.

I think your approach with minted, etc. to gain out of the box  
functionality like this is very useful.  I'm following the  
conversation with interest because I am planning a publication that  
includes some code snippets.  My reservation comes from a decade of  
creating and maintaining LaTeX code.  When I violate the separation of  
semantics and implementation in a .tex file, I come to regret it  
sooner or later.  Old .tex files with non-semantic markup typically  
need editing before they can be used again with a different style file.


Thinking through this a bit more, I can see that this is not really an  
issue if the .org source is always the master document--the .tex file  
can later be regenerated to meet the requirements of a new style.  I  
guess the implementation choice is dependent on the expected use life  
of the LaTeX code generated by org-mode.  If the LaTeX code is just an  
intermediate step in a single process, then it is probably best to  
have org-mode specify all the LaTeX implementation details.  If the  
LaTeX code is the goal, and will have its own use life independent of  
the org-mode file that created it, then the implementation details in  
the .tex file will eventually get in the way.


All the best,
Tom


On Aug 10, 2010, at 7:37 AM, Dan Davison wrote:


"Thomas S. Dye"  writes:


Hi Dan,

One of the design goals of LaTeX is to use semantic markup in the
source and to keep details of representation separate, typically in a
style or class file that is used to render the semantic markup.  From
this perspective, the cleanest implementation would be to create a
LaTeX style or class file for use with org-mode, where the gory
details of listings vs. minted, etc.


Yes, although may I repeat that in the case of minted there are no  
gory

details. The patch I submitted already works to give org users
out-of-the-box pretty fontified code with nothing more required than
installation of pygments and putting minted.sty in a suitable
place. Pending the work on listings that you and Seb and I are
proposing, the minted patch is therefore a useful advance for org
mode. It can always be removed later if it becomes clear that it is
completely redundant in view of newly improved org/listings support.

But yes, absolutely, what you say is definitely helpful for those
planning work on improving listings support.

Dan


could be worked out.  This would
leave org-mode to do what it does very well, which is to identify and
mark the relevant semantic units, and would at the same time simplify
org-mode configuration.

For the user, this would require the org-mode.sty or org-mode.cls  
file

be placed somewhere LaTeX could find it and creating an export target
for it in .emacs.

This might not qualify as "out of the box" but the looser coupling
between org-mode and LaTeX is likely to be a plus in the long run.

All the best,
Tom

On Aug 9, 2010, at 12:29 PM, Dan Davison wrote:




Sébastien Vauban 
writes:


Hi Dan,

Dan Davison wrote:

Sébastien Vauban

writes:
Sebastian Rose wrote:

Dan Davison 
writes:

Can you point me to an example that shows how to make source
code in
latex look (almost) as nice as html?


That is supposed to work with the `listings' package. I havent
tried that
yet.


If I understand you right, here's such an example you're after:

* Much better code


[...]


I've put the PDF (for easy access) onto my Web site:

http://www.mygooglest.com/sva/ECM-Listings.pdf


Wow, that's really nice. Thanks for sharing that.


I really thought that you used such a thing for a long time, having
done so
much for Org-Babel. Maybe you were more interested by the execution
stuff,
rather than its printing? For me, the opposite: I was much
interested by the
printing, now by accessing all the power of Babel.


You're probably right that I should have looked into it. But  
seeing as

the HTML export of code is so nice and requred no configuration, I
never
got round to it. Although I did write my Ph.D. in latex, and I am
enjoying using the listings package for formatting pseudocode in a
paper
which I'm supposed to be writing, I do need to become better friends
with latex, it's true.


I think we should aim to get to a point where org-mode can produce
such
nicely formatted source code out-of-the-box.


I share your point. I'm willing to participate, or even begin, such
a page on
Worg, with the above info.


Maybe we could even make latex inherit the colours and fonts that
emacs is
currently using for source code mark up?


For sure, that'd be nice. You mean the way htmlize works, and keeps
my colors,
right?

Dunno what it implies for Org-LaTeX... Generating your own class
customization,
and having it loaded by default (in the list of LaTeX packages)?


Usage of listings is controlled by the variable
`org-export-latex-listings', so the simplest start would be: if that
is
non-nil then code like yours could be inserted into the latex  
output.





I wa

[Orgmode] ReStructured Text table exporter

2010-08-10 Thread Ethan

Hi,

I found it useful to have Org mode export a table into ReStructured Text.
Here's my code:



;; RST export for orgtbl
(defun orgtbl-to-rst-line (line)
  (apply 'format (cons *org-rst-lfmt* line)))

(defun orgtbl-to-rst (table params)
  "Convert the Orgtbl mode TABLE to ReStructuredText."
  (let* ((hline (concat
 "+-"
 (mapconcat (lambda (width) (apply 'string (make-list width
?-)))
org-table-last-column-widths "-+-")
 "-+"))
 (*org-rst-lfmt* (concat
  "| "
  (mapconcat (lambda (width) (format "%%-%ss"
width))
 org-table-last-column-widths " | ")
  " |"))
 (params2
  (list
   :tstart hline
   :hline hline
   :lfmt 'orgtbl-to-rst-line
   )))
(orgtbl-to-generic table (org-combine-plists params2 params

---

Some questions:

1. I tried to use a format-string directly instead of lfmt pointing to a
function, but when I tried that I got the message:

apply: Not enough arguments for format string

Through some experimentation, you can find that the format string is only
receiving one argument, which is the list of other arguments. I'm guessing
this is a bug in orgtbl-apply-format, and that (apply 'format fmt args)
should be (apply 'format fmt (car args)) or something else.

2. Even if you define your own exporter function, you can't use
org-table-export, because the list of exporters are hard-coded. That's fine,
but in that case, can you add an example on how to use the
TABLE_EXPORT_FORMAT and TABLE_EXPORT_FILE? Just something like the following
in the "Built in table editor" section would have made my life easier.

* Table
  :PROPERTIES:
  :TABLE_EXPORT_FILE: foo.rst
  :TABLE_EXPORT_FORMAT: orgtbl-to-rst
  :END:

Other than that, thanks! Org mode's table editor is pretty useful, and
closer to what I needed than table.el was.

Ethan
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] [babel] strategies for generating multiple graphics files from same code block

Hi Erik,

Given that arbitrary lisp forms can be used to assign header arguments,
the following can be used to achieve this functionality under the
current setup.

--8<---cut here---start->8---
#+Title: Export Target Conditional Header Arguments

The following generates an =.eps= image for LaTeX export and a =.png=
image for html export.
#+begin_src gnuplot :term (if (and (boundp 'latexp) latexp) "postscript" "png") 
:file (if (and (boundp 'latexp) latexp) "sin.eps" "sin.png")
  plot sin(x)
#+end_src
--8<---cut here---end--->8---

So, given that maybe the next development push for babel should focus on
the ability to break header arguments over multiple lines, rather than
on syntactic sugar for the above.

Cheers -- Eric

Erik Iverson  writes:

> Sounds good, and perhaps another 'export' target could be tangling of the 
> code.
>

The above does not address tangling, however this could be fixed by
having ob-tangle could set a tanglep global variable in the spirit of
htmlp and latexp.

>
>
> On 08/09/2010 06:00 PM, Eric Schulte wrote:
>> Hi Erik,
>>
>> There is a planned feature for Org-babel which should subsume these use
>> cases, namely backend-conditional header arguments.  These would allow
>> you to specify different header arguments (including file) depending on
>> the export target, be that html, latex, or none if you are just
>> interactively evaluating inside of an Org-mode buffer.
>>
>> This is still in the early stages, and is waiting until I have a
>> reasonable amount of free time.
>>
>> Cheers -- Eric
>>
>> Erik Iverson  writes:
>>
>>> Hello,
>>>
>>> I'm using org-mode to write R code and generate figures.
>>>
>>> I have multiple files generated per code block, one png and one PDF.
>>> This is so that I can display the graphic:
>>>
>>> 1) Inline in my org-mode buffer (png)
>>> 2) Upon export to HTML, viewable in the browser (png)
>>> 3) Included in a separate PDF, *not* from exporting my org-mode
>>> file.  For this, I would like a PDF version of the graphic to be
>>> generated, and pdflatex can use it (pdf)
>>>
>>> So, for points 1 and 2 above, no problem.
>>>
>>> * Figure 1
>>> Here is the first figure.
>>>
>>> #+begin_src R :file figure1.png :width 960 :exports both :tangle fig1.R
>>>plot(1,1)
>>> #+end_src
>>>
>>> For point 3, I use tangling to write the source code to a file.  I
>>> notice that the graphical code is wrapped by the export process by a
>>> call to png() and dev.off().
>>>
>>> My question, is there any facility to have the tangled code generate a
>>> PDF, instead of PNG?  I still need the png for goals 1 and 2, but the
>>> pdf for goal 3.  Anyone else have any other strategies for realizing
>>> all 3 of my goals?
>>>
>>> I suppose one would be to define a named code block, and use the noweb
>>> syntax:
>>>
>>> Define the plot
>>> #+srcname: fig-test
>>> #+begin_src R
>>>plot(1,1)
>>> #+end_src
>>>
>>> Tangle, but don't export
>>> #+begin_src R :file figure1.pdf :exports none :tangle fig1.R :noweb yes
>>>   <>
>>> #+end_src
>>>
>>> Export, but don't tangle
>>> #+begin_src R :file figure1.png :exports both :noweb yes
>>>   <>
>>> #+end_src
>>>
>>> This is not too bad, but maybe there's an alternative approach?
>>>
>>> Thanks!
>>> Erik Iverson
>>>
>>> ___
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Table caption produces trailing "nil" in pdf export

2010-08-10 Thread John Hendy

Hi,


Suddenly I'm getting a line with nothing but "nil" between the caption and
the table when exporting from org-mode to LaTeX. I swear this not happening.
I believe I did a git pull on Friday or some time last week. The only reason
I noticed is that I just set up emacs, org, and LaTeX on a new computer and
tested an old file to make sure the export was working. I then checked my
other computer with what I thought was a fine install and it's doing it now,
too. I originally thought I missed something on the new computer, but now
I'm wondering if it's from the fresh pull.

I tested three identical tables: 1 "vanilla", 1 with a #+ATTR_LATEX:
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] org-feed XML entities and character encoding

2010-08-10 Thread Michael Brand


Hi all,

org-feed is becoming very useful for me, so far to manage the
episodes of podcasts. Now I have a patch and a request for help.

1. patch for an issue with XML entities
===

I found that some XML entities in my feeds are not substituted. The
comments of two recent org-feed.el commits by David Maus
http://repo.or.cz/w/org-mode.git/commitdiff/6875716e76acfbe1084a47e59d18a30a933d92b6
and
http://repo.or.cz/w/org-mode.git/commitdiff/6875716e76acfbe1084a47e59d18a30a933d92b6
lead me to the thread
http://thread.gmane.org/gmane.emacs.orgmode/26352
and invited me to replace org-feed-unescape with xml-substitute-special
which converts more XML entities. The resulting patch below helps for
me but of course I would like it to be reviewed by an experienced elisp
programmer and org-feed user before being applied.

2. request for help about an issue with multibyte character encoding


There is an issue with multibyte characters that appear in the input
as unescaped, multibyte encoded characters (not as XML entities, as XML
entities multibyte characters are simply substituted correctly). I
looked for an example with a character encoding specified in the first
line of the XML feed like

and found one here:
http://www.openscreencast.de/blog/rss.xml

The W3C validator
http://validator.w3.org
seems to be happy with this feed but when fed into a feeds.org the
unescaped, multibyte encoded characters e. g. of the title `Screencast
076 [...]' get upset, even with `coding: utf-8-unix' in the first line
of the file feeds.org. Can someone please help to get this issue
resolved? If easily possible, like I expect it to be, generally for
all character encodings supported by Emacs? I would even like if
UTF-8 feeds like
http://pod.drs.ch/world_music_special_mpx.xml
that do not have the character encoding specified would work too.

Thanks

- Michael


--- a/lisp/org-feed.el
+++ b/lisp/org-feed.el
@@ -99,6 +99,7 @@
 (declare-function xml-get-children "xml" (node child-name))
 (declare-function xml-get-attribute "xml" (node attribute))
 (declare-function xml-get-attribute-or-nil "xml" (node attribute))
+(declare-function xml-substitute-special "xml" (string))
 (defvar xml-entity-alist)

 (defgroup org-feed  nil
@@ -269,17 +270,6 @@
 (defvar org-feed-buffer "*Org feed*"
   "The buffer used to retrieve a feed.")

-(defun org-feed-unescape (s)
-  "Unescape protected entities in S."
-  (require 'xml)
-  (let ((re (concat "&\\("
-   (mapconcat 'car xml-entity-alist "\\|")
-   "\\);")))
-(while (string-match re s)
-  (setq s (replace-match
-  (cdr (assoc (match-string 1 s) xml-entity-alist)) nil nil s)))
-s))
-
 ;;;###autoload
 (defun org-feed-update-all ()
   "Get inbox items from all feeds in `org-feed-alist'."
@@ -613,6 +603,7 @@

 (defun org-feed-parse-rss-entry (entry)
   "Parse the `:item-full-text' field for xml tags and create new properties."
+  (require 'xml)
   (with-temp-buffer
 (insert (plist-get entry :item-full-text))
 (goto-char (point-min))
@@ -620,7 +611,7 @@
  nil t)
   (setq entry (plist-put entry
 (intern (concat ":" (match-string 1)))
-(org-feed-unescape (match-string 2)
+(xml-substitute-special (match-string 2)
 (goto-char (point-min))
 (unless (re-search-forward "isPermaLink[ \t]*=[ \t]*\"false\"" nil t)
   (setq entry (plist-put entry :guid-permalink t
@@ -633,7 +624,6 @@

 The `:item-full-text' property actually contains the sexp
 formatted as a string, not the original XML data."
-  (require 'xml)
   (with-current-buffer buffer
 (widen)
 (let ((feed (car (xml-parse-region (point-min) (point-max)
@@ -654,7 +644,7 @@
'href)))
 ;; Add  as :title.
 (setq entry (plist-put entry :title
-  (org-feed-unescape
+  (xml-substitute-special
(car (xml-node-children
  (car (xml-get-children xml 'title)))
 (let* ((content (car (xml-get-children xml 'content)))
@@ -664,12 +654,12 @@
 ((string= type "text")
  ;; We like plain text.
  (setq entry (plist-put entry :description
-(org-feed-unescape
+(xml-substitute-special
  (car (xml-node-children content))
 ((string= type "html")
  ;; TODO: convert HTML to Org markup.
  (setq entry (plist-put entry :description
-(org-feed-unescape
+(xml-substitute-special
  (car (xml-node-children content))
 ((string= type "x

Re: [Orgmode] Re: need detailed instructions for submitting the patch

Dan Davison wrote:
>Nick Dokos  writes:

>> Bastien  wrote:
>>
>>
>>> > For example, I have a modified file org-whatever.el. What commands
>>> > must I run?
>>>
>>> Please follow the instructions on Worg and let us know what is not
>>> crystal-clear -- that will help improve the doc if necessary.
>>>
>>
>> I think Dmitry is asking for the git commands and I'm not sure those
>> are described anywhere on Worg.
>>
>> Something like this perhaps:
>>
>>  # create a topic branch to deal with a specific topic: use
>>  # a descriptive name!
>>  git checkout -b topic-branch-foo master
>>  
>>  git commit -a
>>  git format-patch
>>  

>One point I'm not yet clear on:

>For the patchwork system, what methods of inclusion of patch in email
>are acceptable?

>+ attachment type text/plain?
Works.

>+ attachment type text/x-diff?
Works.

>+ attach using C-c C-a in gnus but choose "inline" rather than as
>  "attachment"?

"inline" or "attachment" is irrelevant: It is just a hint to a
displaying MUA how to visualize an attachment (Cf. RFC2183: The
Content-Disposition Header Field).

>+ paste inline?
Should work.

>+ paste inline with special gnus separators --8<-- ?
Dunno.

>does it matter how the patch file is named?
AFAIK it doesn't.

>Also, what requirements are there on how to *reply* so that your message
>gets lumped by patchwork into the same patch item, rather than creating
>a new item? Can the subject line be modified?

AFAIK the subject line doesn't matter because what identifies a
message (for patchtracker and in general) is the message-id header
field.  So it should be a proper reply to the message: Using the
message-id header field in the in-reply-to and references header
field.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpwUGlW9ba3B.pgp
Description: PGP signature
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: [PATCH] Table caption produces trailing "nil" in pdf export

2010-08-10 Thread Nicolas Goaziou

Hello,

> John Hendy writes:

> Suddenly I'm getting a line with nothing but "nil" between the caption and
> the table when exporting from org-mode to LaTeX. I swear this not happening.
> I believe I did a git pull on Friday or some time last week. The only reason
> I noticed is that I just set up emacs, org, and LaTeX on a new computer and
> tested an old file to make sure the export was working. I then checked my
> other computer with what I thought was a fine install and it's doing it now,
> too. I originally thought I missed something on the new computer, but now
> I'm wondering if it's from the fresh pull.

This patch (needed by my own mistake) should correct the problem.

Regards,

-- Nicolas

>From 38a3ae8cf8716af0db87a47a421b6d5af654d045 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Tue, 10 Aug 2010 22:43:35 +0200
Subject: [PATCH] Fix empty label bug

* org-latex.el (org-export-latex-tables): Return "" instead of nil
  when no label is attached.
---
 lisp/org-latex.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 056f1b3..b0ba939 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1683,7 +1683,7 @@ The conversion is made depending of STRING-BEFORE and 
STRING-AFTER."
  "\\caption%s{%s} %s"
  (if shortn (concat "[" shortn "]") "")
  (or caption "")
-(when label (format "\\label{%s}" label
+(if label (format "\\label{%s}" label) "")))
 (if (and longtblp caption) "\n" "\n")
 (if (and org-export-latex-tables-centered (not 
longtblp))
 "\\begin{center}\n")
-- 
1.7.2.1

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Email from org?

Eric Schulte wrote:
>Hi Ethan,

>Ethan Ligon  writes:

>> Eric Schulte  gmail.com> writes:
>>> The following function might get part way towards what you describe.
>>>
>>> --8<---cut here---start->8---
>>> (defun org-send-email-of-headline ()
>>>   (interactive)
>>>   (let ((subject (org-get-heading t))
>>> (to (org-entry-get (point) "mailto")))
>>> (outline-mark-subtree)
>>> (org-mime-org-buffer-htmlize)
>>> (save-excursion
>>>   (message-goto-to) (insert to)
>>>   (message-goto-subject) (insert subject
>>> --8<---cut here---end--->8---
>>>
>>
>> Indeed!  This gets me very close to what I had in mind.  Aside from
>> saying thanks, I have two related things to say:
>>
>> 1) The code snippet above (really org-mime-org-buffer-htmlize)
>> produces output which is either designed to be further processed by
>> the mml library (mml-generate-mime) for gnus users or by the semi
>> library for wanderlust users.  Thus, the buffer resulting from the
>> above code-snippet is still one step away from being something one
>> could feed to smtpmail, and makes the output one needs to get from
>> org-mime dependent on an MUA (gnus or wanderlust).
>>

>I personally like this final step of review before sending an email.

>As for requiring that the user has an mailer with which to send the
>email, it would be possible to change `org-mime-org-buffer-htmlize' to
>use `reporter-submit-bug-report' to send the email directly instead of
>using `reporter-compose-outgoing' which only prepares the email buffer.

>I'm not sure of how to do this while still allowing the existing
>behavior for those who do use Emacs for email.  Also, I find the idea of
>having a key command send an email from an Org-mode buffer without any
>form of confirmation terrifying. :)

I see two problems here: First, adding attachments and/or using
digital encryption and signing.  Second, Messages you've sent this way
are not in your trusted messaging system.

>>
>> 2) I don't see the reason for this dependence.  Forget what mail
>> client the user prefers, whether gnus or wanderlust or something else.

See above.  For me, WL is the tool to handle internet messages.  Org
is from this perspective a layer of abstraction: Org is my personal
realm, internet messages is the connection between me and the outside
world netwise.  Things that come to me are filted in WL, maybe go to
Org -- and things that are in Org are filtered by Org and might go
outside.  It's a important border and thus I strive to improve the
workflow between these two realms.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpZngnlybjKd.pgp
Description: PGP signature
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Table caption produces trailing "nil" in pdf export

John Hendy wrote:
>Hi,

>Suddenly I'm getting a line with nothing but "nil" between the
>caption and the table when exporting from org-mode to LaTeX.  I swear
>this not happening. I believe I did a git pull on Friday or some time
>last week. The only reason I noticed is that I just set up emacs,
>org, and LaTeX on a new computer and tested an old file to make sure
>the export was working. I then checked my other computer with what I
>thought was a fine install and it's doing it now, too. I originally
>thought I missed something on the new computer, but now I'm wondering
>if it's from the fresh pull.

>I tested three identical tables: 1 "vanilla", 1 with a #+ATTR_LATEX:

Could you provide an example Org file to reproduce this behavior?  It
might be also interesting to know the Emacs version (M-x emacs-version
RET) and Org mode version (M-x org-version RET) you use.  If you
execute these two commands, the version are available in the buffer
*Messages*.

Thanks,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpRqT4TCosMc.pgp
Description: PGP signature
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Bug? Table caption produces trailing "nil" in pdf export

John Hendy wrote:
>Drat... some gmail shortcut went off and this thing sent prematurely... here's 
>the rest...

Erm... Forget my last message.  Processing messages sequential has some 
disadvantages ;)

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpIImXcxv659.pgp
Description: PGP signature
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Table caption produces trailing "nil" in pdf export

2010-08-10 Thread John Hendy

@David: Saw your other email, so you should be good to go with the files.
Sorry for the confusion!

@Nicolas: the patch worked. Hopefully I did it right:

$ cd .elisp/org.git/lisp
$ patch < ~/Downloads/0001..bug.patch


Thanks!
John

On Tue, Aug 10, 2010 at 4:07 PM, David Maus  wrote:

> John Hendy wrote:
> >Hi,
>
> >Suddenly I'm getting a line with nothing but "nil" between the
> >caption and the table when exporting from org-mode to LaTeX.  I swear
> >this not happening. I believe I did a git pull on Friday or some time
> >last week. The only reason I noticed is that I just set up emacs,
> >org, and LaTeX on a new computer and tested an old file to make sure
> >the export was working. I then checked my other computer with what I
> >thought was a fine install and it's doing it now, too. I originally
> >thought I missed something on the new computer, but now I'm wondering
> >if it's from the fresh pull.
>
> >I tested three identical tables: 1 "vanilla", 1 with a #+ATTR_LATEX:
>
> Could you provide an example Org file to reproduce this behavior?  It
> might be also interesting to know the Emacs version (M-x emacs-version
> RET) and Org mode version (M-x org-version RET) you use.  If you
> execute these two commands, the version are available in the buffer
> *Messages*.
>
> Thanks,
>  -- David
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber dmj...@jabber.org
> Email. dm...@ictsoc.de
>
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Clock history, C-u C-c C-x C-i not working properly

2010-08-10 Thread Markus Heller

Hello all,

I have had this issue for quite a while, and now it's finally time to
post it.  I'm using emacs 23.2.1 and orgmode 7.01trans
(release_7.01g.73.g29354) on windoze XP, together with Bernt's clock
history setup.

If I hit C-u C-c C-x C-i, the list of tasks to clock in starts
somewhere in the middle, right now at ``[J]''.  I've had this issue on
emacs 22 and with orgmode 6.36 ...

I did remove things related to clock history from my .emacs, with no
effect.

I am not sure how to track this issue down, so if the experts could
provide some hints, that'd be awesome!!

Thanks and Cheers
Markus


___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] text color + highlight

Christian Moe wrote:
>Hi, Eric,

>Thanks for trying this out -- I should have taken the trouble to write
>out sample code myself.

>> Just for completeness I'm adding an example of a color handler which can
>> be added to a users config to enable colorization of exported text to
>> html and latex.
>>
>> --8<---cut here---start->8---
>> (org-add-link-type
>>  "color" nil
>>  (lambda (path desc format)
>>(cond
>> ((eq format 'html)
>>  (format "%s" path desc))
>> ((eq format 'latex)
>>  (format "{\\color{%s}%s}" path desc)
>> --8<---cut here---end--->8---
>>

>A drawback with using links for markup is that the user sees things that
>look like links, but do nothing when clicked, except give error messages.

It's not just a drawback but a more fundamental problem: This solution
abolishes the semantics of a fundamental entity, the link.  color:red
/means/ something completely different than info:elisp.

I'll need some time to read the proposal about this topic but my
out-of-the-guts impression is, that the distinction between semantics
and markup (or visualization) is not drawn as sharp as it is.  For Org
it's all about semantics: If we know what a special sequence of
characters means, we can provide appropriate actions.  One possible
action is to provide special colors etc. as a visual aid.

So maybe don't focus on how to /implement/ visualization but on the
general purpose or meaning of what is /visualized/ (!) by distinct
colors.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de

pgpHre2SLG92r.pgp
Description: PGP signature
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: Insert TODO or plain heading depending on context

2010-08-10 Thread Nathan Neff

Sorry for the bump -- maybe I'll phrase the question differently 

Is there a function in org-mode that returns the TODO
status of the heading that the cursor is currently in?

Thanks,
--Nate

On Thu, Aug 5, 2010 at 10:43 AM, Nathan Neff  wrote:
> Sorry for a rudimentary question, but someone almost certainly has
> done this before:
>
> I'd like define a function that would:
> a) Create a new heading if the cursor is on a heading or the body of a 
> heading.
> or
> b) Create a new TODO heading if the cursor is on a TODO heading or the body
> of a TODO heading.
>
> Essentially, it would be a "smart" function to either press M-Return
> or M-S-Return,
> depending on the context.
>
> I realize I can press M-Return to always create a new heading, and
> M-S-Return to always create a new TODO, but I'd like to eliminate
> an extra keypress for the most common cases.
>
> Any ideas?
>
> Thanks,
> --Nate
>

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: [babel] strategies for generating multiple graphics files from same code block

"Eric Schulte"  writes:

> Hi Erik,
>
> Given that arbitrary lisp forms can be used to assign header arguments,
> the following can be used to achieve this functionality under the
> current setup.
>
> #+Title: Export Target Conditional Header Arguments
>
> The following generates an =.eps= image for LaTeX export and a =.png=
> image for html export.
> #+begin_src gnuplot :term (if (and (boundp 'latexp) latexp) "postscript" 
> "png") :file (if (and (boundp 'latexp) latexp) "sin.eps" "sin.png")
>   plot sin(x)
> #+end_src
>
> So, given that maybe the next development push for babel should focus on
> the ability to break header arguments over multiple lines, rather than
> on syntactic sugar for the above.

Alternatively, I believe we should be able to use sbe to put the elisp
code in blocks:

--8<---cut here---start->8---
#+begin_src gnuplot :term (sbe "get-image-type") :file (sbe "get-file-path")
  plot sin(x)
#+end_src

#+source: get-image-type
#+begin_src emacs-lisp
(if (and (boundp 'latexp) latexp) "postscript" "png")
#+end_src

#+source: get-file-path
#+begin_src emacs-lisp
(if (and (boundp 'latexp) latexp) "sin.eps" "sin.png")
#+end_src
--8<---cut here---end--->8---

As a matter of fact this currently fails on export with 'Invalid read
syntax: "#"', but that's a bug.

Dan

>
> Cheers -- Eric
>
> Erik Iverson  writes:
>
>> Sounds good, and perhaps another 'export' target could be tangling of the 
>> code.
>>
>
> The above does not address tangling, however this could be fixed by
> having ob-tangle could set a tanglep global variable in the spirit of
> htmlp and latexp.
>
>>
>>
>> On 08/09/2010 06:00 PM, Eric Schulte wrote:
>>> Hi Erik,
>>>
>>> There is a planned feature for Org-babel which should subsume these use
>>> cases, namely backend-conditional header arguments.  These would allow
>>> you to specify different header arguments (including file) depending on
>>> the export target, be that html, latex, or none if you are just
>>> interactively evaluating inside of an Org-mode buffer.
>>>
>>> This is still in the early stages, and is waiting until I have a
>>> reasonable amount of free time.
>>>
>>> Cheers -- Eric
>>>
>>> Erik Iverson  writes:
>>>
 Hello,

 I'm using org-mode to write R code and generate figures.

 I have multiple files generated per code block, one png and one PDF.
 This is so that I can display the graphic:

 1) Inline in my org-mode buffer (png)
 2) Upon export to HTML, viewable in the browser (png)
 3) Included in a separate PDF, *not* from exporting my org-mode
 file.  For this, I would like a PDF version of the graphic to be
 generated, and pdflatex can use it (pdf)

 So, for points 1 and 2 above, no problem.

 * Figure 1
 Here is the first figure.

 #+begin_src R :file figure1.png :width 960 :exports both :tangle fig1.R
plot(1,1)
 #+end_src

 For point 3, I use tangling to write the source code to a file.  I
 notice that the graphical code is wrapped by the export process by a
 call to png() and dev.off().

 My question, is there any facility to have the tangled code generate a
 PDF, instead of PNG?  I still need the png for goals 1 and 2, but the
 pdf for goal 3.  Anyone else have any other strategies for realizing
 all 3 of my goals?

 I suppose one would be to define a named code block, and use the noweb
 syntax:

 Define the plot
 #+srcname: fig-test
 #+begin_src R
plot(1,1)
 #+end_src

 Tangle, but don't export
 #+begin_src R :file figure1.pdf :exports none :tangle fig1.R :noweb yes
   <>
 #+end_src

 Export, but don't tangle
 #+begin_src R :file figure1.png :exports both :noweb yes
   <>
 #+end_src

 This is not too bad, but maybe there's an alternative approach?

 Thanks!
 Erik Iverson

 ___
 Emacs-orgmode mailing list
 Please use `Reply All' to send replies to the list.
 Emacs-orgmode@gnu.org
 http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> ___
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Insert TODO or plain heading depending on context

On 08/10/2010 11:41 PM, Nathan Neff wrote:
> Is there a function in org-mode that returns the TODO
> status of the heading that the cursor is currently in?
> 

Yes, try "org-get-todo-state". (Found this using C-h f, typing "org",
then using I-Search in the completion buffer.)
This returns something like this:

#("NEXT" 0 4 (fontified t org-category #("org-dev" 0 7 (fontified t face
org-property-value org-category "projects")) face org-todo))

or nil if there is no TODO state.

This syntax is new to me (elisp noob here), but the elisp reference told
me it's just a string with text properties.

The following code seems to accomplish your goal:

(defun jb/smart-insert-heading ()
  (if (org-get-todo-state)
   (call-interactively 'org-insert-todo-heading)
 (call-interactively 'org-insert-heading)))

HTH, Jan

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] text color + highlight

2010-08-10 Thread Christian Moe


I wrote (against my own suggestion):

A drawback with using links for markup is that the user sees things that
look like links, but do nothing when clicked, except give error messages.


David Maus wrote:

It's not just a drawback but a more fundamental problem: This solution
abolishes the semantics of a fundamental entity, the link.  color:red
/means/ something completely different than info:elisp.


I certainly see that objection. I don't have a strong opinion, I just 
hit on the idea of using custom links as a quick hack to do some inline 
semantic tagging I wanted, then thought it might be worth considering in 
the present discussion, as an alternative to complex new syntaxes.


Quibble: Note that =info:elisp= also means something rather different 
from =shell: ls *org=, =elisp: org-agenda=, or 
=elisp:(find-file-other-frame "Elisp.org")=.


Okay, so Org-babel might put these link types out of business (and 
anyway they unfailingly crash my Emacs 23 for the Mac). But currently 
they /are/ defined as Org links, even though "execute this code" does 
not mean "follow this link". So the double-bracket syntax seems to have 
a broader meaning.


Admittedly, though, all the currently defined link types mean "do 
something when clicked", which a =color:red= link does not.


Christian

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Insert TODO or plain heading depending on context

2010-08-10 Thread Nathan Neff

On Tue, Aug 10, 2010 at 5:07 PM, Jan Böcker  wrote:
> On 08/10/2010 11:41 PM, Nathan Neff wrote:
>> Is there a function in org-mode that returns the TODO
>> status of the heading that the cursor is currently in?
>>
>
> Yes, try "org-get-todo-state". (Found this using C-h f, typing "org",
> then using I-Search in the completion buffer.)
> This returns something like this:
>
> #("NEXT" 0 4 (fontified t org-category #("org-dev" 0 7 (fontified t face
> org-property-value org-category "projects")) face org-todo))
>
> or nil if there is no TODO state.
>
> This syntax is new to me (elisp noob here), but the elisp reference told
> me it's just a string with text properties.
>
> The following code seems to accomplish your goal:
>
> (defun jb/smart-insert-heading ()
>  (if (org-get-todo-state)
>           (call-interactively 'org-insert-todo-heading)
>         (call-interactively 'org-insert-heading)))
>
> HTH, Jan
>

Thanks Jan, this helped a lot!  I appreciate the C-h f reminder -- I
have searched
through org.el and didn't come up with the right search terms.  This
should help me in
the future.

BTW, your function works perfectly!

Thanks,
--Nate

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] text color + highlight

i suggest begin-end pairs, not putting text in the syntax itself.
though you could, if you want, using quotes.

  $[class begin :title animals]Some text about animals$[class end
:title animals]

i wrote the following long ago, but never sent it to
the list.  it is not polished at all -- needs more work that
i cannot do on it now -- and not even capitalized.

this is just one example of many for extensible syntax.
note that the code i provide is for the /user/ to use if he
wants.  the following pretends that color is not a feature
of org and demonstrates that even a /user/, without
modifying any code in org, can actually implement a new
feature with its own "syntax" (actually extensible syntax,
which will never conflict with other features) -- if
extensible syntax becomes a feature of org.

i wrote it in response to somebody requesting color.

it needs work.  for example, s/color/face/g .

===

as far as i know, this is not a feature in org.

however, if extensible syntax were implemented, you could
add this feature to org yourself without touching org source
code or writing any regexps.

here is what it would look like (not what you normally see,
but what you would see if everything were visible).

  here is text in your normal face.  $[color begin :face
  myface :label nil]here is text in myface.  the extensible
  syntax at the beginning has :label nil, which means that
  both ends are invisible except when you are editing them
  or have specified that :label should be ignored.  to make
  them visible, remove or change :label.  you can also
  change the label of the end syntax separately if you want.
  $[color end]here is text in your normal face.

to implement this as a user, you would put something like
this into your .emacs.

  (define-org-syntax color
;;these are the quasiarguments to your feature.  they
;;use common lisp's keyword argument feature.  face
;;defaults to default-face and label defaults to nil,
;;which means to
(begin-or-end &key (face default-face) label)
"Implement my color feature in org."
(cond
  ((equal begin-or-end "begin")
   ;;fixme here you put the emacs code to start a color block
   )
  ((equal begin-or-end "end")
   ;;fixme here you put the emacs code to end a color block
   )
  (otherwise (error "needs to be begin or end"
  (define-key org-mode-map "\C-cc" 'my-insert-color-block)
  (defun my-insert-color-block ()
"Insert a color block."
(interactive)
;;fixme place point between them
(insert "$[color begin :face myface :label nil]$[color end]"))

On 2010-08-09, Christian Moe  wrote:
> Hi,
>
>  >>
>  >> - this would be extensible, e.g.
>  >>
>  >>  [background[yellow] highlighted text]
>  >>
>  >>  could export to the following html
>  >>
>  >>  highlighted text
>  >>
>  >> - this would avoid "{}"s
>  >>
>  >> - this would look more "org-like" than the pure latex solution
>  >>
>  >> the only issue with the above is that it may conflate a new /markup/
>  >> syntax with org-mode's existing /link/ syntax.
>  >>
>  >> Thoughts? -- Eric
>
> I'd like an extensible inline markup construct (not primarily for coloring).
>
> Would it make sense to hijack custom links for this purpose, and use
> existing bracketed link syntax rather than add a new syntax?
>
> For semantic tagging (my chief interest), one might e.g. define a
> `class' link type and an HTML export handler to wrap the contents in
>  tags.
>
> : [[class:animals][some text about animals]]
>
> As for color: If one is satisfied with getting colors on export,
> defining a `color' link type and appropriate export handlers will do.
>
> : [[color:red][some colored text]]
>
> If one also wants the text to appear in the right color within Org-mode,
> and does not want the pseudo-link markup to be underlined and look like
> links, it would require additional Org functionality (I think):
> User-defined custom faces for different link types.
>
 What syntax to use...
>>>
>>> I've thought briefly about the following syntax
>>>
>>> [color[red] text to be colored red]
>>
>> Nope, I am against this syntax.  If we introduce a more general syntax,
>> then it should be done in the way Samuel proposed.  WHich means
>> we firs get a keyword indtroducing the piece, and then properties.
>>
>> Like
>>
>>$[style :color red the red text]
>>
>> or
>>
>>$[face :color :italic t red the red text]
>>
>> Something like the $ before "[" also would seem critical to disambiguate
>> from other uses of "[".
>>
>> However, I am not too excited about extra syntax to get this kind of
>> thing.
>> Would not oppose it, but probably never use it.
>>
>> - Carsten
>
> Those examples are not very readable IMO -- without a separator it's
> hard to see where the property values end and the marked up text begins.
>
> Yours,
> Christian
>
> ___
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@g

Re: [Orgmode] Feature request: IDs on anything

I wrote this a long time ago in response to Carsten's reply
to Eric in the first link below.

===

  1) http://thread.gmane.org/gmane.emacs.orgmode/11896
 extensible syntax with an application in id markers
 (which themselves have an application in many things,
 including graph theoretic constructs such as planning
 tours)
  2) http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10240
 extensible syntax and parsing risk

===

Yes, ID markers are merely link /targets/.  :)

The :link option (which the user can decide to put in or
leave out) turns them into link /sources/ (clickable and
RET-able elements) also.  This allows bidirectional links by
having two ID markers link to each other.[fn:46] A future
post will describe an application.

Perhaps you are thinking of new link features beyond :link?
These are possible, but they are not part of my proposal.

For example, you know how in a browser the links change
color if you have visited them in the last n days?  It
usually seems to be blue links turning red.  That helps you
keep track of things.

If it is ever desired, we can implement this in org.  We add
an option, :last-followed, which contains a timestamp for
the last time you followed the link.  When that timestamp is
within the last n days, org changes the color of the ID
marker's label to red.  (Or it can make it more red the
longer it's been.  Or show how many days it's been.)

I'm *not* saying this feature is necessary, of course (it
isn't).  The point is just that the syntax is robust against
the future, including ideas like this.

P.S.

You don't have to use an ID marker if you never want to
point to it.  If you still wanted fancy link features, then
you could implement something like this instead of using ID
markers.

  $[link http://google.com
 :last-followed [2009-02-27 Fri 02:00]
 :label "click here for evil search engine"
 :export-label "click here for nice search engine"]

(I threw in an export label just for fun.)

But I'm only proposing ID markers (and extensible syntax).

[fn:46] :link enables bidirectional links, rings, DAGs,
tours (e.g. for tutorials), multiple planning sequences,
Bayes nets, decision trees that span the outline's ontology
structure, and adventure games.  In graph-theoretic terms,
an ID marker that uses the :link option is an =arc=;
wherever you place it becomes a =node=.  Arcs can be
unidirectional or bidirectional.

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] extensible syntax example using link features

I wrote this a very long time ago but did not send it to the list.
(There is more where this came from.)

Samuel

===

Here is an arbitrary example of extensible link syntax.
This one allows two features we don't currently have: link
coloring and a different label for when the link is
exported.  This is merely an example.

  $[link http://google.com
 :last-followed [2009-02-25 Wed 02:00]
 :label "click here for evil search engine"
 :export-label "click here for nice search engine"]

"link" means that it is a link.  This part of the syntax
says what kind of thing you are dealing with.  It could also
be "id" for an ID marker, or "timestamp" for a fancy
timestamp, or whatever you want to use the syntax for.  But
here we are only specifying a link.

"click here for evil search engine" replaces all of the text
just as in existing link syntax.  Thus that is all you see
in org-mode unless M-x visible-mode or start editing.  This
is just as with existing link syntax.  The timestamp allows
the coloring feature.  The link can be red if the link was
followed in the last 30 days, and blue otherwise.

I am not proposing either the label feature or the coloring
feature.  They are just examples of what you can do.

Note that you can also add features any time you want
without breaking syntax.  If you want to add :export-color
or :followed-face and :not-followed-face
and :followed-expiry-days, you CAN.

In the case of a proposed annotation mechanism, we can
have :start and :end for a region, or :search for something
to search for, or :emacs-tag to use a tag.  We are not
hamstrung by whatever design we choose.  Later, we can
retire a feature and add another, if we want.

We modify the mode line in the target to indicate that there
is an annotation.

Bidirectional, of course.

===

  1) http://thread.gmane.org/gmane.emacs.orgmode/11896
 extensible syntax with an application in id markers
 (which themselves have an application in many things,
 including graph theoretic constructs such as planning
 tours)
  2) http://thread.gmane.org/gmane.emacs.orgmode/10204/focus=10240
 extensible syntax and parsing risk

===


-- 
Q: How many CDC "scientists" does it take to change a lightbulb?
A: "You only think it's dark." [CDC has denied a deadly disease for 25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Feature request: IDs on anything

On 2010-08-10, Samuel Wales  wrote:
> I wrote this a long time ago in response to Carsten's reply
> to Eric in the first link below.

I guess it was a response to Eric.

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] text color + highlight

Christian Moe  writes:

[...]
>
> Admittedly, though, all the currently defined link types mean "do
> something when clicked", which a =color:red= link does not.
>

well this may be trivial, but at least it's an action
--8<---cut here---start->8---
(org-add-link-type
 "color"
 (lambda (path)
   (message (concat "color "
(progn (add-text-properties
0 (length path)
(list 'face `((t (:foreground ,path
path) path
 (lambda (path desc format)
   (cond
((eq format 'html)
 (format "%s" path desc))
((eq format 'latex)
 (format "{\\color{%s}%s}" path desc)
--8<---cut here---end--->8---

Best -- Eric

>
> Christian

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: Tip: How to copy&paste a table from Firefox to Org

2010-08-10 Thread Bernt Hansen

Jan Böcker  writes:

> Hi all,
>
> posting in case this is useful to someone else:
>
> I just figured out how to copy & paste tabular data from Firefox to an
> Org buffer (in my case: a train schedule from www.bahn.de).
>
> - Select data in Firefox
> - Paste into Org, select it as the region
> - M-x replace-regexp  C-i \ | ^  | 
>   
>   C-i inserts a tab character (you can also use C-q  instead).
>   We replace each beginning of a line and each tab character with "|".
>
> - Place the cursor on the table and press C-c C-c to align it

Isn't this the same as

  - Select data in Firefox
  - Paste into Org. 
  - C-x C-x (select it as the region)
  - M-x org-table-convert-region

?

-Bernt

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: Clock history, C-u C-c C-x C-i not working properly

2010-08-10 Thread Bernt Hansen

Markus Heller  writes:

> Hello all,
>
> I have had this issue for quite a while, and now it's finally time to
> post it.  I'm using emacs 23.2.1 and orgmode 7.01trans
> (release_7.01g.73.g29354) on windoze XP, together with Bernt's clock
> history setup.
>
> If I hit C-u C-c C-x C-i, the list of tasks to clock in starts
> somewhere in the middle, right now at ``[J]''.  I've had this issue on
> emacs 22 and with orgmode 6.36 ...

My list on Windows XP, Emacs 23.2.1 is also a bit weird.  The choices
for my list are:

[d] [1] [2] [5] [6] [7] [8] [9] [A] [B] [C] [D] [M] [O] [R]

On linux with a full clock history I get

[d] [1] [2] ... [9] [A] [B] ... [R] [S] with no gaps

I've noticed problems with the menu on my EEE PC which has a reduced
screen size so it couldn't display the entire menu and displayed the end
instead of beginning of the menu.  I've since reduced
org-clock-history-length from 36 to 28 so it fits on that device.

-Bernt

>
> I did remove things related to clock history from my .emacs, with no
> effect.
>
> I am not sure how to track this issue down, so if the experts could
> provide some hints, that'd be awesome!!
>
> Thanks and Cheers
> Markus
>
>
> ___
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: ReRe[2]: need detailed instructions for submitting the patch

2010-08-10 Thread Noorul Islam K M

"Thomas S. Dye"  writes:

> Aloha Dmitry,
>
> Another reason for working in topic branches is it leaves your master
> branch clean so that changes in the remote are easily merged.  You're
> are probably more computer savvy than I am, but my struggles with
> merges after making changes to the master branch have been trying.  I
> try to leave master clean at all times now.
>

I would like to try this approach. I have been finding it very hard to
maintain the master branch with the other approach.

Thanks
Noorul

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: Tip: How to copy&paste a table from Firefox to Org

On 08/11/2010 03:42 AM, Bernt Hansen wrote:
> Jan Böcker  writes:
> 
>> Hi all,
>>
>> posting in case this is useful to someone else:
>>
>> I just figured out how to copy & paste tabular data from Firefox to an
>> Org buffer (in my case: a train schedule from www.bahn.de).
>>
>> - Select data in Firefox
>> - Paste into Org, select it as the region
>> - M-x replace-regexp  C-i \ | ^  | 
>>  
>>   C-i inserts a tab character (you can also use C-q  instead).
>>   We replace each beginning of a line and each tab character with "|".
>>
>> - Place the cursor on the table and press C-c C-c to align it
> 
> Isn't this the same as
> 
>   - Select data in Firefox
>   - Paste into Org. 
>   - C-x C-x (select it as the region)
>   - M-x org-table-convert-region
> 
> ?
> 
> -Bernt

Yes, it is.
I should read the manual more often to discover cool features like that!

Btw, org-table-convert-region is also bound to C-c |, which would make
the steps:

- select data in firefox
- C-y  C-x C-x  C-c |

Thanks a lot, Bernt! You see, that's the other reason I posted: I knew
if I had overlooked a much faster way, someone would point it out to me :)

- Jan

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] text color + highlight

On 08/11/2010 01:14 AM, Samuel Wales wrote:
> i suggest begin-end pairs, not putting text in the syntax itself.
> though you could, if you want, using quotes.
> 
>   $[class begin :title animals]Some text about animals$[class end
> :title animals]
> 

Why not allow both? If I want to highlight one or two words, maybe I
could use:

$[class :title animals "African swallow"]

Compare this to:
$[class begin :title animals]African swallow$[class end :title animals]

For a few sentences and to get support for nested formatting, I would
definitely want begin-end pairs, too, but if you want to highlight a few
words, being able to put text into the syntax itself makes things a lot
shorter.

As far as I understand it, once a framework for this extensible syntax
is in place, it would not be too hard to support both variants.

BTW, I really like the idea of having extensible syntax in general; this
could also make inline todos a lot less painful. I do not know enough
about elisp and Org to help with the implementation, but if someone
wants to implement this and needs help with testing, I'd be glad to
help. (I wrote my last exam today, so I will have a lot more time to
spare until October.)

Jan

___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[Orgmode] Re: text color + highlight