Re: [O] Skim.app support for org-mac-link-grabber.el

[Daniil Frumin]

OK, here's a patch which adds the ability to highlight the selected text.

It makes new highlight notes only if `org-mac-Skim-highlight-selection-p' is 
set to t.


- Dan



0004-Add-the-ability-to-highlight-the-selected-text-in-Sk.patch
Description: Binary data

On May 14, 2013, at 8:33 AM, Carsten Dominik  wrote:

> 
> On 13.5.2013, at 22:35, Daniil Frumin  wrote:
> 
>> So I've been researching this problem and it seems that there is no sane way 
>> to re-select a text. 
> 
> OK, thanks for looking into it.
> 
>> 
>> The problem is that `(do-applescript ..)' only interacts with AppleScript 
>> well if the return type of the string is either a number or a string. If I 
>> try to convert the selection object (which is not really an object but a 
>> list of specifiers) it just returns the selected text. 
>> 
>> There is also `selection bounds' but it only covers rectangle selections.
>> 
>> It's possible to save the selected text and try to `find' it later, but that 
>> won't work well (e.g.: there are several repetitions of the same text on one 
>> page). 
>> 
>> I've also tried to implement an auto-scrolling to the selected text, but to 
>> no avail.
>> 
>> The option that seems to me the most reasonable is to add a highlight note 
>> to the selected text (which is actually possible). What do you think? 
> 
> Interesting idea!  I think this should be implemented, but with a user option 
> to turn it off.
> 
>> 
>> For now, the patch to the problem mentioned by Ivan.
>> I have actually fixed a small bug in the code for getting links from Firefox:
>> Prior to the fix the firefox link grabber won't work correctly if a cursor 
>> has been already positioned in the URL field. The fix works by adding an 
>> additional keystore for selecting all the text in that field.
>> 
>> The problem is that I've committed it before committing the stuff that Ivan 
>> told us about, so I am not sure what to do in this case.
> 
> So you mean the patch you would like to send to me is several commits?  That 
> is no problem, just specify with git which range of commits should be part of 
> the patch, for example
> 
>git diff HEAD^^
> 
> will include the changes from two commits.  You could also amend the previous 
> commit if it has not yet been push to another repository - there are many 
> ways to deal with this.
> 
> - Carsten
> 
>> 
>> Thanks
>> 
>> -- Daniil
>> 
>> <0002-Fixing-a-bug-in-as-mac-firefox-get-frontmost-url.patch><0003-Automatic-detection-of-the-presence-of-Skim.app.patch>
>> 
>> 
>> On May 13, 2013, at 10:34 AM, Carsten Dominik  
>> wrote:
>> 
>>> Hi Daniil,
>>> 
>>> I like this a lot and would like to take the patch after you have taken 
>>> Ivans feedback, and maybe more feedback if you get any.
>>> 
>>> I would like it even more if following the link would rehighlight the 
>>> selected text.  Is there any way to achieve this?
>>> 
>>> I have another question, this would maybe be for the original author, 
>>> Anthony Lander?  I see that there are functions with prefixes that are not 
>>> "org-".  This is dangerous because there might be packages around that use 
>>> that name space.  I also think it violates coding rules in Emacs.  I think 
>>> this should be changed - unless you know of a convention that all functions 
>>> dealing with applescripts are supposed to have an "as-" prefix.
>>> 
>>> I can fix this - but I wanted your feedback first.
>>> 
>>> Thanks.
>>> 
>>> - Carsten
>>> 
>>> On 12 mei 2013, at 20:29, Daniil Frumin  wrote:
>>> 
 Hi, all!
 
 I use org-mac-link-grabber.el 
  almost 
 every day. However, it lacks support for an app that I'd like to use 
 together with org-mode. 
 
 Skim.app is a light and fast PDF reader for Mac OS X with a note-taking 
 ability. I wrote a little patch for org-mac-link-grabber.el to support 
 grabbing links to documents.
 
 What it does:
 
 * Grabs not just the link to file, but a page
 
 * Inserts the selected text as a description, if present. Otherwise
 inserts ", p. "
 
 * The shortcut is set to [S]
 
 * Defines a new "skim" link type
 
 It would be interesting to also add some support for importing notes from 
 Skim to org.
 
 Since Skim.app is not present in clean OS X installs, by default support 
 for grabbing links from it is disabled. You can enable it by customizing 
 group `org-mac-link-grabber'.
 
 So, maybe it's possible to get this patch into the tree? It's my first 
 time hacking on org (or even any major elisp extension), so it's probably 
 that I've messed up somewhere with a commit format or whatnot.
 
 Cheers.
 
 -- Daniil Frumin
 <0001-Adding-Skim.app-support-to-org-mac-link-grabber.el.patch>
>>> 
>> 
> 

Re: [O] org-mime

[Joseph Vidal-Rosset]

2013/5/13 Eric Schulte 

> A while back Org-mode switched its method of exporting latex equations
> to HTML.  Equations used to be exported as png images, however they are
> now exported as markup which may then be processed on the fly by
> client-side javascript.  Most mail readers do not allow javascript in
> html email, and I doubt that the required javascript headers are
> included in the mail html mime part.
>

Thanks Eric for your precise reply. Does it means that there is a sort of
bug in Thunderbrid or that another configuration of Thunderbird could solve
this problem? In this case, I consider that I can write succesfully LaTeX
equations in Gnus or Wanderlust and that is a good news !

Thanks again.

Jo.

[O] bug#14379: bug#14379: bug#14379: Several Org source files cannot be loaded in isolation

[ASSI]

On Monday 13 May 2013, 15:32:45, Eric Schulte wrote:
> I'm still getting an error with the following.
> 
> $ emacs -batch -l lisp/ob-C.el
> Symbol's value as variable is void: org-babel-tangle-lang-exts

Depending on which Emacs version you use and whether, where and how Org 8 is 
installed and initialized, you'll need something like

$ emacs -Q -batch -l org8-init.el -l lisp/ob-C.el

for testing, to avoid pulling in the wrong autoloads.  This won't be a 
problem once Org 8 is integrated into Emacs, but you need to be careful with 
standalone Org.

> I can eliminate the error if I remove
> 
>   (defvar org-babel-tangle-lang-exts)
> 
> from ob-C.el, and add an explicit require to ob-tangle.  I have no idea
> why the explicit require works, but requiring /through/ ob.el does not
> work.  I can make these changes if it is important to be able to load
> these source files individually.

I'll test that again once more to be sure, but this should really be fixed 
already.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: [O] Skim.app support for org-mac-link-grabber.el

[Carsten Dominik]

On 13.5.2013, at 22:35, Daniil Frumin  wrote:

> So I've been researching this problem and it seems that there is no sane way 
> to re-select a text. 

OK, thanks for looking into it.

> 
> The problem is that `(do-applescript ..)' only interacts with AppleScript 
> well if the return type of the string is either a number or a string. If I 
> try to convert the selection object (which is not really an object but a list 
> of specifiers) it just returns the selected text. 
> 
> There is also `selection bounds' but it only covers rectangle selections.
> 
> It's possible to save the selected text and try to `find' it later, but that 
> won't work well (e.g.: there are several repetitions of the same text on one 
> page). 
> 
> I've also tried to implement an auto-scrolling to the selected text, but to 
> no avail.
> 
> The option that seems to me the most reasonable is to add a highlight note to 
> the selected text (which is actually possible). What do you think? 

Interesting idea!  I think this should be implemented, but with a user option 
to turn it off.

> 
> For now, the patch to the problem mentioned by Ivan.
> I have actually fixed a small bug in the code for getting links from Firefox:
> Prior to the fix the firefox link grabber won't work correctly if a cursor 
> has been already positioned in the URL field. The fix works by adding an 
> additional keystore for selecting all the text in that field.
> 
> The problem is that I've committed it before committing the stuff that Ivan 
> told us about, so I am not sure what to do in this case.

So you mean the patch you would like to send to me is several commits?  That is 
no problem, just specify with git which range of commits should be part of the 
patch, for example

git diff HEAD^^

will include the changes from two commits.  You could also amend the previous 
commit if it has not yet been push to another repository - there are many ways 
to deal with this.

- Carsten

> 
> Thanks
> 
> -- Daniil
> 
> <0002-Fixing-a-bug-in-as-mac-firefox-get-frontmost-url.patch><0003-Automatic-detection-of-the-presence-of-Skim.app.patch>
> 
> 
> On May 13, 2013, at 10:34 AM, Carsten Dominik  
> wrote:
> 
>> Hi Daniil,
>> 
>> I like this a lot and would like to take the patch after you have taken 
>> Ivans feedback, and maybe more feedback if you get any.
>> 
>> I would like it even more if following the link would rehighlight the 
>> selected text.  Is there any way to achieve this?
>> 
>> I have another question, this would maybe be for the original author, 
>> Anthony Lander?  I see that there are functions with prefixes that are not 
>> "org-".  This is dangerous because there might be packages around that use 
>> that name space.  I also think it violates coding rules in Emacs.  I think 
>> this should be changed - unless you know of a convention that all functions 
>> dealing with applescripts are supposed to have an "as-" prefix.
>> 
>> I can fix this - but I wanted your feedback first.
>> 
>> Thanks.
>> 
>> - Carsten
>> 
>> On 12 mei 2013, at 20:29, Daniil Frumin  wrote:
>> 
>>> Hi, all!
>>> 
>>> I use org-mac-link-grabber.el 
>>>  almost 
>>> every day. However, it lacks support for an app that I'd like to use 
>>> together with org-mode. 
>>> 
>>> Skim.app is a light and fast PDF reader for Mac OS X with a note-taking 
>>> ability. I wrote a little patch for org-mac-link-grabber.el to support 
>>> grabbing links to documents.
>>> 
>>> What it does:
>>> 
>>> * Grabs not just the link to file, but a page
>>> 
>>> * Inserts the selected text as a description, if present. Otherwise
>>> inserts ", p. "
>>> 
>>> * The shortcut is set to [S]
>>> 
>>> * Defines a new "skim" link type
>>> 
>>> It would be interesting to also add some support for importing notes from 
>>> Skim to org.
>>> 
>>> Since Skim.app is not present in clean OS X installs, by default support 
>>> for grabbing links from it is disabled. You can enable it by customizing 
>>> group `org-mac-link-grabber'.
>>> 
>>> So, maybe it's possible to get this patch into the tree? It's my first time 
>>> hacking on org (or even any major elisp extension), so it's probably that 
>>> I've messed up somewhere with a commit format or whatnot.
>>> 
>>> Cheers.
>>> 
>>> -- Daniil Frumin
>>> <0001-Adding-Skim.app-support-to-org-mac-link-grabber.el.patch>
>> 
> 

Re: [O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

Hi Nicolas,

On Mon, May 13, 2013 at 6:54 AM, Nicolas Goaziou  wrote:
>
> You can still number these parts manually with, e.g.,
>
>   #+latex: \section*{Introduction}
>
> before the first section in your Org document.
>

While this is possible, wouldn't this break the structure of the
org-document, so that a section no longer corresponds to a headline in
some cases.  Also, when the un-numbered section is at the same level
as the top-level headlines, then there would be no way of cleanly
folding away its content in emacs.  Furthermore, by manually inserting
LaTeX code, you make it non-portable for other exporters.

>> 2. a document where only one of the headlines and its child-headlines
>> halfway through the document should be un-numbered (maybe they
>> represent an "example docoument" embedded within an
>> instruction-manual).
>
> I may be wrong, but this sounds like a hypothetical use case to me.

I have certainly encountered cases like this, where I will resort to
using pure LaTeX, but it would be obviously more convenient to be able
to work on such documents via org-mode.

> Anyway, your patch will not work on back-ends that rely on Org to
> compute section numbers (e.g., ascii, html...) because even if you
> ignore numbering for a particular headline, it still adds up internally.
> IOW, you also need to patch `org-export--collect-headline-numbering'.
>
> But that's not quite it, yet. Some back-ends (e.g., html) use that
> internal number as a unique identifier for the headline. Actually, the
> "artificial restriction" you are talking about is a way to allow every
> headline to be numbered in a unique way, even if that number doesn't
> appear in the output.

I can see what you mean here -- but it doesn't exactly "break"
anything -- it just makes the section-numbering within html, etc.
documents to be non-consecutive *if these properties are used*.  If
the main intent is to use these properties in conjunction with the
LaTeX exporter, then this isn't a big problem (i.e. those who want to
use them will just need to understand that they currently only work
"correctly" with LaTeX, but that this will be fixed in the future).

> Since I wouldn't use this, I can hardly judge, but I would appreciate
> some feedback from other users before we go too far in the
> implementation.

Agreed, but my (obviously biased) opinion is that it makes manual
numbering-control more "natural" within org-mode, and something which
doesn't require as much hacking with embedded LaTeX (or HTML, etc.)
code.

Regards,

Mark

Re: [O] ox-bibtex.el references working in sample.org

[Thomas S. Dye]

Aloha George,

Perhaps what we want is illustrated by figure [[fig:WhatWeWant]]

#+caption[What we want in TOC]: What we want under the figure.
#+name: fig:WhatWeWant

George Jones  writes:

> What we want is illustrated by figure \ref{WhatWeWant}
>
> #+CAPTION: What we want
> #+LABEL: fig:WhatWeWant

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

[O] ox-bibtex.el references working in sample.org

[George Jones]

Both LaTeX and HTML citations and bibliography generation in the new
ox-bibtex.el
seem to be working.

Test .org file attached

Ran it with a larger document I'm working on, and the references seemed to
work.
Having some issues now with figures and references, but I'm probably just
using old-style stuff here.   Next battle.

What we want is illustrated by figure \ref{WhatWeWant}

#+CAPTION: What we want
#+LABEL: fig:WhatWeWant

Thanks for your work/help,
---George Jones


simple.org
Description: Binary data

Re: [O] OT: Annotating PDF & Org

[Ramon Diaz-Uriarte]

To set the (new) record straight:

> On Tue, 7 May 2013 00:44 Ramon Diaz-Uriarte  gmail.com> writes:

(...)

[Talking about Okular]

> Note, though, that incorporating annotations in the PDF itself, which
> means you use the "Save As", is somewhat of a pain, because by default the
> file name and directory are not reasonable, in my opinion; see this
> feature request: https://bugs.kde.org/show_bug.cgi?id=319042. (This is why
> I now do most of my paper reading/PDF annotation in the tablet, even if I
> have no keyboard there).


As of 45 minutes ago that is no longer the case, because the bug has been
fixed/the request has been honored.

https://projects.kde.org/projects/kde/kdegraphics/okular/repository/revisions/460502d1240ae5eaa865b3e2873a23322b836ebf

https://bugs.kde.org/show_bug.cgi?id=319042



R.



(...)

On Tue, 7 May 2013 16:39:42 -0500,Russell Adams  
wrote:
> On Tue, May 07, 2013 at 11:36:31PM +0200, Ramon Diaz-Uriarte wrote:
> > - Annotate/highlight the PDF, keeping the annotations in the PDF itself
> >   (when on the computer I use Okular, and "Save As"; if in the tablet, I
> >   use ezPDF or similar). I emphasize this: the annotations are in the PDF
> >   itself (i.e., if you open the PDF with evince, acrobat reader, whatever,
> >   you'll see them there).

> My understanding was that Okular didn't update the PDF, it had a
> mini-database. You're saying if you save the PDF again it'll combine
> the annotations?

> --
> Russell Adamsrlad...@adamsinfoserv.com

> PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

> Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina 
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

Re: [O] using gnuplot's "splot" and "every" commands on org-mode table data

[Eric Schulte]

Paul Stansell  writes:

> Hi Eric,
>
> In your last example are you illustrating the case of a data file with
> missing data?

Yes.

> Replacing ""s with blank space in your example doesn't really break
> the plot, it's just that gnuplot interprets the first column of data
> as
>
> 1
> 2
> 3
> 16
>
> 6
> 7
> 4
> 9
>
> and the second as
>
> 2
> 4
> 8
>
>
> 16
> 8
> 4
> 2
>

I would consider this breaking the plot, in that gnuplot no longer lines
up the two columns of data.

>
> Gnuplot has a specific setting for handling missing values.  It's
> common in gnuplot to use '?' to signify a missing value (type "help
> missing" at the gnuplot prompt).  If, in your last example, you
> replace the missing values with '?' (without the quotes) and then type
> in gnuplot
>
>   set datafile missing "?"
>
> and then plot the data with
>
>   plot "data.txt" u 0:1, '' u 0:2
>
> you'll see that gnuplot handles it properly.  Putting '?' in the
> blanks cells of the org mode table in your last attachment and
> plotting from within org mode gives a temporary data file containing
> '"?"', which gnuplot also handles correctly as it must recognise "?"
> (with the quotes) as being a missing value.
>
> But org mode's behaviour of inserting "" in blank cells (instead of
> actual blanks) does break the use of "every" in gnuplot which is
> required by splot when plotting surfaces from data files (unless the
> data files are in "matrix" format).  Also, inserting "" breaks the use
> of gnuplot's "index" which expects two blank lines to separate data
> sets in a single file, but I've never used this facility.
>
> I noticed that org mode writes table values of 'nan' and 'NaN' without
> the double quotes, but, for example, 'MaM' is written with double
> quotes, (as ''"MaM"') in the temporary data file.
>

I didn't know that '?' was the standard gnuplot missing value.  In that
case I think the `org-babel-gnuplot-table-to-data' should be updated to
replace missing values with '?' by default.  If we find a common need to
specialize this value then we can add a gnuplot header argument which
can specify missing values for particular code blocks.

>
> Also, I think it's generally better to remove the double quotes from
> around all strings exported by org mode for plotting by gnuplot as
> they're generally not needed (exceptions are strings which contain
> spaces which can be quoted so they are treated as a single entity by
> gnuplot).  For example, there is a gnuplot demonstration script called
> datastrings.dem which plots data from a file called ctg-y2.dat.  This
> data file has unquoted month names in the first column that are
> plotted as labels on the x-axis.
>

I agree with your reasoning here.  This and the above should be fairly
straightforward changes to the `org-babel-gnuplot-table-to-data'
function.  If I find any free time I'll make these changes.  Although I
certainly wouldn't mind if someone else gets to them first.

Best regards (and thanks for the clear explanations),

>
> Paul

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] using gnuplot's "splot" and "every" commands on org-mode table data

[Eric Schulte]

Achim Gratz  writes:

> Eric Schulte writes:
>> This does look like a bug to me.  Can you isolate "where" the value of
>> data in your example is first assigned the wrong value?
>
> The error lies in how ob-sh tries to determine if it needs to process a
> table or a vector and then forgets to check for 'hline, thus ending up
> in the vector branch with the table data.
>
>> Thanks for reporting.  I will save your example for when I next have
>> development time.
>
> Here's a suggestion for a quick fix.  I've also implemented :hlines
> processing for ob-sh (it was ignoring that header arg unconditionally)
> and added an experimental header arg :hline-string to control how hlines
> get actually exported.  BTW, trailing blank lines in the output get
> swallowed when re-importing to Org, I'm not sure if that is supposed to
> happen or not.
>

This looks great.  Please go ahead and apply this patch to ob-sh.

>
> Giving ob-gnuplot (and possible ob-awk, which also uses
> orgtbl-to-generic) a similar treatment would allow to do this directly
> without going through ob.sh of course.
>

That sounds like a good solution to me.  Generally whenever a solution
may be made in a generic support function instead of a language specific
file I would consider that a win.  If you have a good implementation
here I'd be very happy if you applied it.

Cheers,

>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] org-mime

[Eric Schulte]

Joseph Vidal-Rosset  writes:

>Hello,
>
>I just made a clean installation of org packages and contrib in order
>to
>be able to convert latex equations in gnus. But I meet the following
>problem that I am going to describe:
>
>Generating a png image seems to work via M-x org-preview-latex-fragment
>\begin{equation} ((A \to B) \to A) \to A \end{equation}
>
>But with M-x org-mime-htmlize, the png image is not loaded. Why? Your
>help is welcome.
>
>-

A while back Org-mode switched its method of exporting latex equations
to HTML.  Equations used to be exported as png images, however they are
now exported as markup which may then be processed on the fly by
client-side javascript.  Most mail readers do not allow javascript in
html email, and I doubt that the required javascript headers are
included in the mail html mime part.

I don't know if it is currently possible to do the javascript
pre-processing as part of the HTML export, but that would probably be
the best solution in this case.

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

[O] bug#14379: bug#14379: bug#14379: Several Org source files cannot be loaded in isolation

[Eric Schulte]

Achim Gratz  writes:

> Carsten Dominik writes:
>> I have asked Eric to fix these.
>
> These errors do not exist in Org 8 anymore, in other words they are
> already fixed (by the introduction of ob-core, as it were).
>

I'm still getting an error with the following.

$ emacs -batch -l lisp/ob-C.el
Symbol's value as variable is void: org-babel-tangle-lang-exts

I can eliminate the error if I remove

  (defvar org-babel-tangle-lang-exts)

from ob-C.el, and add an explicit require to ob-tangle.  I have no idea
why the explicit require works, but requiring /through/ ob.el does not
work.  I can make these changes if it is important to be able to load
these source files individually.

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] Skim.app support for org-mac-link-grabber.el

[Daniil Frumin]

So I've been researching this problem and it seems that there is no sane way to 
re-select a text. 

The problem is that `(do-applescript ..)' only interacts with AppleScript well 
if the return type of the string is either a number or a string. If I try to 
convert the selection object (which is not really an object but a list of 
specifiers) it just returns the selected text. 

There is also `selection bounds' but it only covers rectangle selections.

It's possible to save the selected text and try to `find' it later, but that 
won't work well (e.g.: there are several repetitions of the same text on one 
page). 

I've also tried to implement an auto-scrolling to the selected text, but to no 
avail.

The option that seems to me the most reasonable is to add a highlight note to 
the selected text (which is actually possible). What do you think? 

For now, the patch to the problem mentioned by Ivan.
I have actually fixed a small bug in the code for getting links from Firefox:
Prior to the fix the firefox link grabber won't work correctly if a cursor has 
been already positioned in the URL field. The fix works by adding an additional 
keystore for selecting all the text in that field.

The problem is that I've committed it before committing the stuff that Ivan 
told us about, so I am not sure what to do in this case.

Thanks

-- Daniil



0002-Fixing-a-bug-in-as-mac-firefox-get-frontmost-url.patch
Description: Binary data


0003-Automatic-detection-of-the-presence-of-Skim.app.patch
Description: Binary data



On May 13, 2013, at 10:34 AM, Carsten Dominik  wrote:

> Hi Daniil,
> 
> I like this a lot and would like to take the patch after you have taken Ivans 
> feedback, and maybe more feedback if you get any.
> 
> I would like it even more if following the link would rehighlight the 
> selected text.  Is there any way to achieve this?
> 
> I have another question, this would maybe be for the original author, Anthony 
> Lander?  I see that there are functions with prefixes that are not "org-".  
> This is dangerous because there might be packages around that use that name 
> space.  I also think it violates coding rules in Emacs.  I think this should 
> be changed - unless you know of a convention that all functions dealing with 
> applescripts are supposed to have an "as-" prefix.
> 
> I can fix this - but I wanted your feedback first.
> 
> Thanks.
> 
> - Carsten
> 
> On 12 mei 2013, at 20:29, Daniil Frumin  wrote:
> 
>> Hi, all!
>> 
>> I use org-mac-link-grabber.el 
>>  almost every 
>> day. However, it lacks support for an app that I'd like to use together with 
>> org-mode. 
>> 
>> Skim.app is a light and fast PDF reader for Mac OS X with a note-taking 
>> ability. I wrote a little patch for org-mac-link-grabber.el to support 
>> grabbing links to documents.
>> 
>> What it does:
>> 
>> * Grabs not just the link to file, but a page
>> 
>> * Inserts the selected text as a description, if present. Otherwise
>> inserts ", p. "
>> 
>> * The shortcut is set to [S]
>> 
>> * Defines a new "skim" link type
>> 
>> It would be interesting to also add some support for importing notes from 
>> Skim to org.
>> 
>> Since Skim.app is not present in clean OS X installs, by default support for 
>> grabbing links from it is disabled. You can enable it by customizing group 
>> `org-mac-link-grabber'.
>> 
>> So, maybe it's possible to get this patch into the tree? It's my first time 
>> hacking on org (or even any major elisp extension), so it's probably that 
>> I've messed up somewhere with a commit format or whatnot.
>> 
>> Cheers.
>> 
>> -- Daniil Frumin
>> <0001-Adding-Skim.app-support-to-org-mac-link-grabber.el.patch>
> 

Re: [O] diff in `src' blocks

[Samuel Wales]

On 5/13/13, Achim Gratz  wrote:
> All things considered, there may be room for an argument that Babel
> shouldn't ignore the data from STDOUT on non-zero exit or have an option
> to ignore the return code for cases like this.

That sounds good for newcomers.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.

Re: [O] BIND and LaTeX export

[Fabrice Popineau]

2013/5/13 Nicolas Goaziou 

> Hello,
>
> Fabrice Popineau  writes:
>
> > Is it me or something is wrong with the very latest org-mode (git
> > repository).
> > I have this line in my org-file :
> >
> > #+BIND: org-latex-pdf-process ("pdflatex -interaction nonstopmode
> > -shell-escape -output-directory %o %f")
> >
> > My default value for this variable states that lualatex is used for
> > compilation.
> > Even using the BIND line, it is still lualatex which is used.
> > And I have set org-export-allow-bind-keywords to t.
> >
> > I'm pretty sure it worked a couple of days ago.
>
> I'm surprised it even worked. BIND keywords only affect the export
> process, i.e. Org to LaTeX translation in this case. File compilation to
> PDF is a post-processing thing, these keywords don't survive that long.
>
>
I may have been fooled by my emacs config.
But anyway, given the name org-latex-*,
I thought that it could make sense that this variable survive
till the end of the compilation :-)



> You may use file local variables instead.
>
>
Thanks for the hint.

Fabrice

[O] Inhibit default EMAIL in derived exporter

[Viktor Rosenfeld]

Hi,

commit 16f12e0 changed how the EMAIL option is configured in a derived
exporter that also uses this keyword.

In `contrib/ox-koma-letter.el', the koma-letter exporter configures the default
of the EMAIL option to the variable `org-koma-letter-email'. However, since
commit 16f12e0, if the option is missing, the default is set to
`user-mail-address' which is the default for the standard LaTeX exporter.

The current code causes the following bug in koma-letter exporter: If EMAIL is
missing, and `org-koma-letter-email' is `nil', then the exporter should not set
a email address in the exported LaTeX file. The rationale is that the email
address is configured in an external LCO file (and can be overwritten for an
individual letter, if desired). However, the new behavior causes the email to
be set explicitly, overwriting the value from the LCO file.

Consider the following example:

#+BEGIN_SRC org
#+LATEX_CLASS: my-letter
#+LCO: DefaultAddress
#+END_SRC

The expected LaTeX-code is:

#+BEGIN_SRC latex
\documentclass{scrlttr2}
\LoadLetterOption{DefaultAddress}% <--- email is set here
% ...
\begin{document}
% ...
\end{document}
#+END_SRC

However, since commit 16f12e0, the generated code is:

#+BEGIN_SRC latex
\documentclass{scrlttr2}
\LoadLetterOption{DefaultAddress}% <--- email is set here
\setkomavar{fromemail}{he...@client204-235.wlan.hu-berlin.de}  % <--- email is 
overwritten here
% ...
\begin{document}
% ...
\end{document}
#+END_SRC

Is this a bug in the LaTeX exporter or is this the intended behavior? Should I
maybe use another keyword instead of EMAIL? I think I used SENDER instead of
AUTHOR because of a similar conflict.

Cheers,
Viktor

Re: [O] Exporting visible items not behaving as expected

[Cameron Desautels]

Yessir, I see the expected behavior now (with the upgrade). Many thanks.

-- 
Cameron Desautels 


On Wed, May 8, 2013 at 3:13 AM, Nicolas Goaziou  wrote:

> Hello,
>
> Cameron Desautels  writes:
>
> > I'm having a bit of trouble with exports. My understanding is that I
> should
> > be able to create a sparse tree from a tag (C-c / m tag-name RET) and
> then
> > export only the visible items (C-c C-e C-v t A) to get an export of just
> > the items with that tag. What I'm getting instead is an export that only
> > contains the top-level headers and I'm uncertain why this is happening.
> Any
> > advice would be greatly appreciated. Details follow:
>
> The visible-only code was over simplistic. I fixed it in maint, so your
> example should export fine now.
>
> Thank you for reporting this.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] diff in `src' blocks

[Achim Gratz]

Achim Gratz writes:
>> Is this this a bug?
>
> I don't think so, although Babel could give a more enlightening message
> about why it didn't evaluate STDOUT.  It gives this on your original example:
>
> Babel evaluation exited with code 1
> Code block produced no output.

All things considered, there may be room for an argument that Babel
shouldn't ignore the data from STDOUT on non-zero exit or have an option
to ignore the return code for cases like this.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] BIND and LaTeX export

[Nicolas Goaziou]

Hello,

Fabrice Popineau  writes:

> Is it me or something is wrong with the very latest org-mode (git
> repository).
> I have this line in my org-file :
>
> #+BIND: org-latex-pdf-process ("pdflatex -interaction nonstopmode
> -shell-escape -output-directory %o %f")
>
> My default value for this variable states that lualatex is used for
> compilation.
> Even using the BIND line, it is still lualatex which is used.
> And I have set org-export-allow-bind-keywords to t.
>
> I'm pretty sure it worked a couple of days ago.

I'm surprised it even worked. BIND keywords only affect the export
process, i.e. Org to LaTeX translation in this case. File compilation to
PDF is a post-processing thing, these keywords don't survive that long.

You may use file local variables instead.


Regards,

-- 
Nicolas Goaziou

Re: [O] Export options for subheadings

[Nicolas Goaziou]

Hello,

JBash  writes:

> I'm having a problem getting the export options for single subtree to work.
>  I'm exporting to pdf.  I'm not sure the information in the manual applies
> to the new exporter (since I'm not sure C-c @ applies anymore... I've tried
> it, and get the same results as putting the cursor on the subheading, and
> doing C-c C-e C-s l p.  I've attached a test file.

Indeed, marking a subtree with C-c @ don't trigger subtree export anymore.

> From the manual:
>
> "When exporting only a single subtree by selecting it with C-c @ before
> calling an export command, the subtree can overrule some of the file's
> export settings with properties EXPORT_FILE_NAME, EXPORT_TITLE, EXPORT_TEXT
> , EXPORT_AUTHOR, EXPORT_DATE, and EXPORT_OPTIONS."

For some reason, your manual is out of date. You can have a look at the
one published on the Org site.

> * Major Heading 1
> #+EXPORT_FILE_NAME: test_subheading_export1.pdf
> #+EXPORT_TITLE: Test Export of a Subtree Overrides - 1
> #+EXPORT_DATE: 2013-05-11

You are confusing keywords and node properties. On the previous
headline, use C-c C-e, toggle subtree export with C-s, then call # RET
to see what should be inserted instead.


Regards,

-- 
Nicolas Goaziou

[O] Automatic "mailto:" links when exporting to html

[Philippe Coatmeur]

Hello everyone

This is my first message here ; My name is Phil ; Please excuse my bad 
english and general noobiness.


I need email addresses to become clickable "mailto:"; links in my docs ; 
I'm in the (quite tedious I must say) process of writing a function that 
would do that :


 * Replace valid.email-adr...@somed0main.ext
 * with
   
[[mailto:valid.email-adr...@somed0main.ext][valid.email-adr...@somed0main.ext]]

But maybe there's a native way to tell org-mode to do it at export time 
that I did not find ? I carefully examined the "Org Export HTML group: " 
and the "Org Export General group: " customize groups but found nothing 
relevant..?


This is such a logical way of doing things that I wanted to ask you, how 
do you do this ?


Thank you for your time,

Phil

[O] Export options for subheadings

[JBash]

Hello,

I'm having a problem getting the export options for single subtree to work.
 I'm exporting to pdf.  I'm not sure the information in the manual applies
to the new exporter (since I'm not sure C-c @ applies anymore... I've tried
it, and get the same results as putting the cursor on the subheading, and
doing C-c C-e C-s l p.  I've attached a test file.  The export ignores the
EXPORT_FILE_NAME, EXPORT_TITLE, and EXPORT_DATE in the subtree.

It may well be a problem with my configuration, so if it's working y'all,
please let me know and, if you have suggestions about possible
configuration problems, I'd appreciate hearing them.

Thanks,
Jerry

Org-mode version 8.0.2 (release_8.0.2-119-g646f1a / emacs 23.4.1 / debian
sid

>From the manual:

"When exporting only a single subtree by selecting it with C-c @ before
calling an export command, the subtree can overrule some of the file's
export settings with properties EXPORT_FILE_NAME, EXPORT_TITLE, EXPORT_TEXT
, EXPORT_AUTHOR, EXPORT_DATE, and EXPORT_OPTIONS."


test_export_subtree.org
Description: Binary data

Re: [O] disable tangling for an entire section?

[Bill White]

On Mon May 13 2013 at 03:23, rai...@krugs.de (Rainer M. Krug) wrote:

> Christian Moe  writes:
>
>>> I was hoping that a higher-level setting would override all tangle
>>> settings under it, no matter what they might be.  This would make it
>>> possible to change an entire section's tangling without fussing with
>>> each code block's setting.
>>
>> The status quo makes more sense, I think. It allows you to easily change
>> an entire section's tangling but make specific exceptions that
>> override the general setting.
>
> I agree with Christian here. But you could trick org into achieving
> what you want, in specifying a tangle target in the PROPERTIES sectio,
> given that you only use :tangle yes :

I wish I'd thought of that!  Many thanks -

bw

Re: [O] unexpected appearance of x^2 in pdf file

[Nicolas Richard]

Paul Stansell  writes:
> Yes, I tried that, but as I understand it I need to
> \usepackage{amsmath} to access the latex equation* environment. 

Usually amsmath is good to have (and Nicolas answered on how to include
it), but if you wish to avoid it for some reason, the {displaymath}
environment does the same thing.

-- 
N.

[O] BMCOL column width as absolute?

[James Harkins]

Hi, in the new beamer exporter, are there any plans to support an
absolute width for columns, rather than a fraction of \textwidth?

hjh

[O] BIND and LaTeX export

[Fabrice Popineau]

Hi,

Is it me or something is wrong with the very latest org-mode (git
repository).
I have this line in my org-file :

#+BIND: org-latex-pdf-process ("pdflatex -interaction nonstopmode
-shell-escape -output-directory %o %f")

My default value for this variable states that lualatex is used for
compilation.
Even using the BIND line, it is still lualatex which is used.
And I have set org-export-allow-bind-keywords to t.

I'm pretty sure it worked a couple of days ago.

Thanks for any help,

-- 
Fabrice

Re: [O] [mobileorg-android] Re: Agenda in MobileOrg for Android

[Marcin Borkowski]

Dnia 2013-05-13, o godz. 11:00:49
James Harkins  napisał(a):

> > OK, so I'm reviving this old thread.
> >
> > I tried to set up MobileOrg again and failed completely - again.
> > Sorry for my post being a bit harsh, but I'm really frustrated with
> > this situation, especially that I hear people claiming it works for
> > them...
> 
> For the sake of completion, and so that MobileOrg doesn't get too bad
> a rap, discussion of the MobileOrg/Android config issue continued on
> the MobileOrg/Android mailing list.

Thanks for resending it here, James - I certainly do not want to give
the impression that MobileOrg is a crap - as you write below, most
probably (as I expected) the problem lies at my side.

> One main point:
> 
> Any versions of MobileOrg (for android) with the new interface (I
> think 0.9.5+, but I don't remember the exact version number) depend on
> some new code in org-mode itself to handle pulling. Marcin was using
> an older org version, which doesn't include the new stuff. This is
> almost certainly the cause of the pull failures reported here.
> 
> I think it's only within the last 4-6 weeks that some org-mobile-pull
> bugs were fixed in org, so in general, the newer the org version, the
> better. For myself, with those bug fixes, pulling from mobile is "just
> working."
> 
> I'll leave off any discussion of the interface issues, except to note
> that the MobileOrg/Android developers are more than willing to listen
> to user experiences. (I'm not one of those developers, just a
> generally satisfied user.)

To confirm this, I have to admit (sadly) that despite the fact that I
acted like a complete jerk with my frustration-filled email, I got a
lengthy and detailed response from one of these devs there.  (And now
I'm working to rebuild my reputation there to level 0...)

> hjh

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] link_up and link_home

[Vikas Rawal]

> 
> > Has there been a change in the way #+link_up and #+link_home are used
> > in html export?
> 
> You need to use #+HTML_LINK_UP and #+HTML_LINK_HOME now.
> 
Thanks.

Vikas

Re: [O] link_up and link_home

[Bastien]

Hi Vikas,

Vikas Rawal  writes:

> Has there been a change in the way #+link_up and #+link_home are used
> in html export?

You need to use #+HTML_LINK_UP and #+HTML_LINK_HOME now.

HTH,

-- 
 Bastien

[O] link_up and link_home

[Vikas Rawal]

Has there been a change in the way #+link_up and #+link_home are used
in html export?

Vikas

[O] Indentation of code blocks within lists

[Francesco Pizzolante]

Hi All,

I'd like to let you know about issues I'm having while trying to put source
code blocks within lists.

Here's my example and how I indent it:

--8<---cut here---start->8---
* First situation

- My first bullet

  We need to do this:

  #+begin_src emacs-lisp
  (message "this is a string")
  (defun x()
"Doc..."
(interactive)
(message "hello"))
  #+end_src

- My second bullet

  #+begin_src emacs-lisp
  "test"
  #+end_src

  #+results:
  : test

  - Sub-point of second bullet

We need to do this as well:

#+begin_src emacs-lisp
(sort)
#+end_src
--8<---cut here---end--->8---

This way if indenting code blocks has the following advantages:

- it looks nice;

- thanks to the indentation, you directly know at which list level the code
  block belongs to;

- you can easily use Emacs commands (like `C-x TAB') on regions or Org
  promote/demote commands on items or subtrees to edit and reorganize your
  text: "relative" indentation is preserved in all cases.

But, I have 2 issues with it:

- when using `C-c '' (`org-edit-special'), I see spaces before my code, while
  I would expect to see my code starting at column 0 in the edit buffer (the
  "reference" column for the "margin" being, here, the column with the '#'
  from '#+begin_src';

- when exporting, the spaces from column 0 to the start of my code are also
  exported, while I would again expect these spaces to be ignored for the
  export.

The only way I found to fix these issues is to edit my text like this (and
make any code to start in column 0):

--8<---cut here---start->8---
- My first bullet

  We need to do this:

  #+begin_src emacs-lisp
(message "this is a string")
(defun x()
  "Doc..."
  (interactive)
  (message "hello"))
  #+end_src

- My second bullet

  #+begin_src emacs-lisp
"test"
  #+end_src

  #+results:
  : test

  - Sub-point of second bullet

We need to do this as well:

#+begin_src emacs-lisp
(sort)
#+end_src
--8<---cut here---end--->8---

But:

- as you can see, the text does not look anymore as nice as in the previous
  example;

- I'm no longer able to edit and reorganize the text using Emacs `C-x TAB'
  command. That command becomes "forbidden" as it can't correctly respect the
  indentation requirements:

  + starting at column 0 for code;

  + relative for list items (depending on their depth);

- even Org promote/demote commands are buggy in this case: as a simple
  example, when I try to promote (with M-Shift-Left) the last point "Sub-point
  of second bullet" I get an error ("indent-line-to: Wrong type argument:
  wholenump, -2" ) and the following half-baked result:

--8<---cut here---start->8---
  - Sub-point of second bullet

We need to do this:

#+begin_src emacs-lisp
(sort)
  #+end_src
--8<---cut here---end--->8---

  The "#+end_src" line got misaligned.

So, my question is the following: is there a way to edit my text as shown in
the first example and edit/export it ignoring the "margin" spaces?

Any help is welcome.

Thanks a lot,
 Francesco

Re: [O] [PATCH] Export: Override headline numbering via properties

[Nicolas Goaziou]

Hello,

Mark Edgington  writes:

> A couple possible use-cases:
>
> 1. a document (or chapter of a document) where the first  headline
> contains general "introduction" information explaining what the rest
> of the document (chapter) is about (similar to an abstract, but not
> identical -- something that might contain sub-headings, lists, tables,
> etc.), and the remainder of the document (chapter) is the "real"
> content of the document -- the place where you want the numbering to
> begin.

You can still number these parts manually with, e.g.,

  #+latex: \section*{Introduction}

before the first section in your Org document.

> 2. a document where only one of the headlines and its child-headlines
> halfway through the document should be un-numbered (maybe they
> represent an "example docoument" embedded within an
> instruction-manual).

I may be wrong, but this sounds like a hypothetical use case to me.

Anyway, your patch will not work on back-ends that rely on Org to
compute section numbers (e.g., ascii, html...) because even if you
ignore numbering for a particular headline, it still adds up internally.
IOW, you also need to patch `org-export--collect-headline-numbering'.

But that's not quite it, yet. Some back-ends (e.g., html) use that
internal number as a unique identifier for the headline. Actually, the
"artificial restriction" you are talking about is a way to allow every
headline to be numbered in a unique way, even if that number doesn't
appear in the output.

Therefore, you need to generate a unique identifier for all headlines,
a function to return it, and modify each back-end accordingly. This is
obviously doable, but it cannot fit in a TINYPATCH.

Since I wouldn't use this, I can hardly judge, but I would appreciate
some feedback from other users before we go too far in the
implementation.


Regards,

-- 
Nicolas Goaziou

Re: [O] Skim.app support for org-mac-link-grabber.el

[Carsten Dominik]

On 13 mei 2013, at 11:53, Daniel F  wrote:

> Hi Carsten, Ivan.
> 
> Thanks for the feedback. The issue that Ivan mentioned does look important 
> and I'll try to fix it asap and incorporate the check.
> I'll also look into the rehilighting thing, I am not sure if that's possible. 
> I guess it also would be nice to scroll not just to the right page, but also 
> to the right line in the text.
> 
> As for the "as-" prefix I just assumed that this is legit because the package 
> was already present in the org-mode.

Yes, I see that this is also done in org-mac-message.el. H.

- Carsten

> 
> Cheers.
> 
> - Dan
> 
> 
> On Mon, May 13, 2013 at 10:34 AM, Carsten Dominik  
> wrote:
> Hi Daniil,
> 
> I like this a lot and would like to take the patch after you have taken Ivans 
> feedback, and maybe more feedback if you get any.
> 
> I would like it even more if following the link would rehighlight the 
> selected text.  Is there any way to achieve this?
> 
> I have another question, this would maybe be for the original author, Anthony 
> Lander?  I see that there are functions with prefixes that are not "org-".  
> This is dangerous because there might be packages around that use that name 
> space.  I also think it violates coding rules in Emacs.  I think this should 
> be changed - unless you know of a convention that all functions dealing with 
> applescripts are supposed to have an "as-" prefix.
> 
> I can fix this - but I wanted your feedback first.
> 
> Thanks.
> 
> - Carsten
> 
> On 12 mei 2013, at 20:29, Daniil Frumin  wrote:
> 
> > Hi, all!
> >
> > I use org-mac-link-grabber.el 
> >  almost 
> > every day. However, it lacks support for an app that I'd like to use 
> > together with org-mode.
> >
> > Skim.app is a light and fast PDF reader for Mac OS X with a note-taking 
> > ability. I wrote a little patch for org-mac-link-grabber.el to support 
> > grabbing links to documents.
> >
> > What it does:
> >
> > * Grabs not just the link to file, but a page
> >
> > * Inserts the selected text as a description, if present. Otherwise
> >  inserts ", p. "
> >
> > * The shortcut is set to [S]
> >
> > * Defines a new "skim" link type
> >
> > It would be interesting to also add some support for importing notes from 
> > Skim to org.
> >
> > Since Skim.app is not present in clean OS X installs, by default support 
> > for grabbing links from it is disabled. You can enable it by customizing 
> > group `org-mac-link-grabber'.
> >
> > So, maybe it's possible to get this patch into the tree? It's my first time 
> > hacking on org (or even any major elisp extension), so it's probably that 
> > I've messed up somewhere with a commit format or whatnot.
> >
> > Cheers.
> >
> > -- Daniil Frumin
> > <0001-Adding-Skim.app-support-to-org-mac-link-grabber.el.patch>
> 
> 
> 
> 
> -- 
> Sincerely yours,
> -- Daniil

Re: [O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

Also, I forgot to mention that the patch is tested, and behaves as expected.

On Mon, May 13, 2013 at 2:18 AM, Nicolas Goaziou  wrote:
> Thanks for your patch.
>
> Though, I don't get what you are trying to achieve nor what a use case
> would be. Have you tested this patch ? It may not behave as you expect
> it to.

Re: [O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

Hi Samuel,

I'd guess it isn't exactly the same as what you did -- I assume you
are making it possible to modify the numbering level threshold via
properties.  Is this modification inherited by child-headlines or not?
 Either way, there would be a lot of "hackery" required to use this to
achieve the kinds of things my patch intends to do  (e.g. you might
have to use different num:x properties in multiple places to cause
just a single-headline's numbering to be changed).

Regards,

Mark


On Mon, May 13, 2013 at 12:39 AM, Samuel Wales  wrote:
> I just did this, is this related?
>
> :PROPERTIES:
> :EXPORT_OPTIONS: num:1
> :END:
>
> --
> The Kafka Pandemic: http://thekafkapandemic.blogspot.com
>
> The disease DOES progress.  MANY people have died from it.  ANYBODY can get 
> it.

Re: [O] Skim.app support for org-mac-link-grabber.el

[Daniel F]

Hi Carsten, Ivan.

Thanks for the feedback. The issue that Ivan mentioned does look important
and I'll try to fix it asap and incorporate the check.
I'll also look into the rehilighting thing, I am not sure if that's
possible. I guess it also would be nice to scroll not just to the right
page, but also to the right line in the text.

As for the "as-" prefix I just assumed that this is legit because the
package was already present in the org-mode.

Cheers.

- Dan


On Mon, May 13, 2013 at 10:34 AM, Carsten Dominik  wrote:

> Hi Daniil,
>
> I like this a lot and would like to take the patch after you have taken
> Ivans feedback, and maybe more feedback if you get any.
>
> I would like it even more if following the link would rehighlight the
> selected text.  Is there any way to achieve this?
>
> I have another question, this would maybe be for the original author,
> Anthony Lander?  I see that there are functions with prefixes that are not
> "org-".  This is dangerous because there might be packages around that use
> that name space.  I also think it violates coding rules in Emacs.  I think
> this should be changed - unless you know of a convention that all functions
> dealing with applescripts are supposed to have an "as-" prefix.
>
> I can fix this - but I wanted your feedback first.
>
> Thanks.
>
> - Carsten
>
> On 12 mei 2013, at 20:29, Daniil Frumin  wrote:
>
> > Hi, all!
> >
> > I use org-mac-link-grabber.el <
> http://orgmode.org/worg/org-contrib/org-mac-link-grabber.html> almost
> every day. However, it lacks support for an app that I'd like to use
> together with org-mode.
> >
> > Skim.app is a light and fast PDF reader for Mac OS X with a note-taking
> ability. I wrote a little patch for org-mac-link-grabber.el to support
> grabbing links to documents.
> >
> > What it does:
> >
> > * Grabs not just the link to file, but a page
> >
> > * Inserts the selected text as a description, if present. Otherwise
> >  inserts ", p. "
> >
> > * The shortcut is set to [S]
> >
> > * Defines a new "skim" link type
> >
> > It would be interesting to also add some support for importing notes
> from Skim to org.
> >
> > Since Skim.app is not present in clean OS X installs, by default support
> for grabbing links from it is disabled. You can enable it by customizing
> group `org-mac-link-grabber'.
> >
> > So, maybe it's possible to get this patch into the tree? It's my first
> time hacking on org (or even any major elisp extension), so it's probably
> that I've messed up somewhere with a commit format or whatnot.
> >
> > Cheers.
> >
> > -- Daniil Frumin
> > <0001-Adding-Skim.app-support-to-org-mac-link-grabber.el.patch>
>
>


-- 
Sincerely yours,
-- Daniil

Re: [O] Babel blocks not indented

[Andreas Röhler]

[ ... ]

I change my mode to whatever my src is in when I want indenting to work
properly, then change it back when I want to see it as an org file again.

Dave





Probably it would pay to have a minor mode for that, running with idle-timer 
and switching the mode according to SRC context.

Andreas

Re: [O] [PATCH] Export: Override headline numbering via properties

[Mark Edgington]

Hello Nicolas,

I'm sorry for not having provided more explanation of the patch's
purpose.  The motivation is basically to permit any kind of "manual"
(in contrast to "automatic") control over the section-numbering
behavior connected with a particular headline.  In LaTeX, for example,
you are able to make any section numbered or un-numbered, however in
org-mode, there is an artificial restriction when using numbering that
sections of a particular depth must be either all numbered, or all
un-numbered.

A couple possible use-cases:

1. a document (or chapter of a document) where the first  headline
contains general "introduction" information explaining what the rest
of the document (chapter) is about (similar to an abstract, but not
identical -- something that might contain sub-headings, lists, tables,
etc.), and the remainder of the document (chapter) is the "real"
content of the document -- the place where you want the numbering to
begin.

2. a document where only one of the headlines and its child-headlines
halfway through the document should be un-numbered (maybe they
represent an "example docoument" embedded within an
instruction-manual).

The reason there are two different properties (a normal, and an
"inherited" version) is because use-case #2 could be painful if you
had to add a ":NUMBERED: n" property to every node of the
sub-document.  There are probably several other use-cases to be
discovered that this allows.  Simply put, the patch makes it possible
to control the numbering for a single headline (one specific headline,
not a headline-level), or to set a manual default numbering behavior
for a sub-tree of headlines.  All other headlines behave according to
the current org-mode numbering rules.

Regards,

Mark

Re: [O] Babel blocks not indented

[Leo Alekseyev]

On Fri, May 10, 2013 at 3:32 PM, Nick Dokos  wrote:

> Leo Alekseyev  writes:
>
> > I've brought this up before, but I think there's value in SRC blocks
> > /not/ being indented, and in fact, I would love it if there were a way
> > to make the contents of the SRC blocks / not/ be indented (as opposed
> > to the default 2 space offset).   Whitespace often matters,
> > particularly when working with Python, and every now and then I find
> > myself having to manually delete the extra spacing when pasting code
> > into the Python interpreter.  Other times I want to paste code
> > snippets from SRC blocks into source files -- again, indentation gets
> > in the way.  I agree that it's aesthetically appealing, but my
> > workflow would be easier without it.
> >
>
> > --Leo
> >
>
> Does this help?
>
> ,
> | org-edit-src-content-indentation is a variable defined in `org-src.el'.
> | Its value is 2
> |
> | Documentation:
> | Indentation for the content of a source code block.
> | This should be the number of spaces added to the indentation of the
> #+begin
> | line in order to compute the indentation of the block content after
> | editing it with M-x org-edit-src-code.  Has no effect if
> | `org-src-preserve-indentation' is non-nil.
> `
>
> --
> Nick
>
>
> Yes! I had no idea this existed!  I could've sworn I've asked about this
before and came up empty :/

Re: [O] diff in `src' blocks

[Oliver Večerník]

>> Figured out myself, sorry for the noise.  It has to do with the exit
>> status of the `diff', which is 1 if the files are different.  So I use
>> the pipe through `cat'.
>
> Useless use of cat...

At least the return status is zero.  But I agree with you, a colon is
better here.  This is my first use of a `:' btw.  I never had case
before.

-- 
Thanks,
Oliver

Re: [O] diff in `src' blocks

[Achim Gratz]

Oliver Večerník  vecernik.at> writes:
> Figured out myself, sorry for the noise.  It has to do with the exit
> status of the `diff', which is 1 if the files are different.  So I use
> the pipe through `cat'.

Useless use of cat...


Regards,
Achim

Re: [O] diff in `src' blocks

[Achim Gratz]

Oliver Večerník  vecernik.at> writes:
> Why is the `diff' command alone not exported while the piped `diff' via
> `cat' works?

The exit code is not zero since diff found differences, so Babel assumes the
script produced an error.  Try this instead when you don't know what the
return code of the last command will be or if you know that it isn't zero
even when no error occured:

#+BEGIN_SRC sh :exports results :results output
diff testdiff.txt.orig testdiff.txt
:
#+END_SRC

> Is this this a bug?

I don't think so, although Babel could give a more enlightening message
about why it didn't evaluate STDOUT.  It gives this on your original example:

Babel evaluation exited with code 1
Code block produced no output.



Regards,
Achim.

Re: [O] disable tangling for an entire section?

[Rainer M. Krug]

Christian Moe  writes:

>> I was hoping that a higher-level setting would override all tangle
>> settings under it, no matter what they might be.  This would make it
>> possible to change an entire section's tangling without fussing with
>> each code block's setting.
>
> The status quo makes more sense, I think. It allows you to easily change
> an entire section's tangling but make specific exceptions that
> override the general setting.

I agree with Christian here. But you could trick org into achieving what
you want, in specifying a tangle target in the PROPERTIES sectio, given
that you only use :tangle yes :

* headline
:PROPERTIES:
:tangle:   tmp.tmp
:END:

#+begin_src perl :tangle yes
2 + 2
#+end_src
#+begin_src perl :tangle no
3 + 3
#+end_src
 

In this case, the the first code block can be tangled into tmp.tmp and
the second one won't. So no harm done to your "clean" tangled file, only
the tmp.tmp, which you can discard afterwords.

Cheers,

Rainer

>
> Yours,
> Christian
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: [O] diff in `src' blocks

[Oliver Večerník]

> Why is the `diff' command alone not exported while the piped `diff' via
> `cat' works?  Is this this a bug?

Figured out myself, sorry for the noise.  It has to do with the exit
status of the `diff', which is 1 if the files are different.  So I use
the pipe through `cat'.

[O] diff in `src' blocks

[Oliver Večerník]

Hi,

in the following org file the second block gets not exported (tested with
text and html exporter, release_8.0.2-119-g646f1a):

--8<---cut here---start->8---
#+OPTIONS: toc:nil author:nil

#+BEGIN_SRC sh :exports results :results output
cat testdiff.txt.orig
#+END_SRC

#+BEGIN_SRC sh :exports results :results output
diff testdiff.txt.orig testdiff.txt
#+END_SRC

#+BEGIN_SRC sh :exports results :results output
diff testdiff.txt.orig testdiff.txt | cat
#+END_SRC

#+BEGIN_SRC sh :exports results :results output
ls testdiff.*
#+END_SRC
--8<---cut here---end--->8---

   __

TESTDIFF
   __


,
| asdf
| ghjk
`

,
| 1c1
| < asdf
| ---
| > qwer
`

,
| testdiff.html
| testdiff.org
| testdiff.txt
| testdiff.txt.orig
`

Why is the `diff' command alone not exported while the piped `diff' via
`cat' works?  Is this this a bug?

-- 
Regards,
Oliver