Re: [Orgmode] BUG ??? Cannot export custom link type to ASCII :-(

[Sebastian Rose]

Carsten Dominik  writes:

> Hi Sebastian,
>
> On Sun, Sep 5, 2010 at 3:37 AM, Sebastian Rose  wrote:
>> Hi,
>>
>>
>> I have problems to export a custom link type to ASCII.
>>
>> The code is here:
>>
>>   http://github.com/SebastianRose/org-osm/blob/master/org-osm-link.el
>>
>>   line 66 ff.
>
>
> Do you mean that it does not honor your export formatting as defined
> in org-osm-link-export ?


Exactly.

This affects bbdb: links as well.  file: links work as expected (or as I
expect??).

* Test links

  [[track:((9.707032442092896 52.37033874553582) (9.711474180221558 52.375238282987))2010-test-file.svg][test-track]]
  [[track:((9.707032442092896 52.37033874553582) (9.711474180221558 52.375238282987))unterverzeichnis/testtrack.svg][test-track im Unterverzeichnis]]
  [[bbdb:Sebastian%20Rose][Sebastian Rose, Hannover]]
  [[file:~/emacs/gnus/News/drafts/drafts/1::This%20affects%20bbdb%20links%20as%20well][Mail to Carsten]]

Exports to  ASCII like this:

1 Test links 
~

  [test-track]
  [test-track im Unterverzeichnis]
  [Sebastian Rose, Hannover]
  [Mail to Carsten]



  [test-track]: track:((9.707032442092896 52.37033874553582) (9.711474180221558 52.375238282987))2010-test-file.svg
  [test-track im Unterverzeichnis]: track:((9.707032442092896 52.37033874553582) (9.711474180221558 52.375238282987))unterverzeichnis/testtrack.svg
  [Sebastian Rose, Hannover]: bbdb:Sebastian%20Rose
  [Mail to Carsten]: file:~/emacs/gnus/News/drafts/drafts/1::This%20affects%20bbdb%20links%20as%20well


Hmmm  this seems so deliberate...  For bbdb links this even seems to
make sense...  But how could I avoid this "footnote like" behaviour?



  Sebastian


>>
>>
>> HTML export works as expected.
>>
>>
>> Example Org file:
>>
>>  --8<---cut here---start->8--
>>
>> * Test links
>>
>>  [[track:((9.707032442092896 52.37033874553582) (9.711474180221558 
>> 52.375238282987))FILENAME.svg][DESCRIPTION]]
>>
>>  --8<---cut here---end--->8--
>>
>>
>>
>>
>> Results in ASCII (just the section with the link):
>>
>>  --8<---cut here---start->8--
>>
>> 1 Test links
>> ~
>>
>>  [DESCRIPTION]
>>
>>  [DESCRIPTION]: track:((9.707032442092896 52.37033874553582) 
>> (9.711474180221558 52.375238282987))FILENAME.svg
>>
>>
>>  --8<---cut here---end--->8--
>>
>>
>>
>> HTML works:
>>
>>  --8<---cut here---start->8--
>>
>> 
>> 1 Test links 
>> 
>>
>>
>> 
>> DESCRIPTION
>> 
>> 
>> ...
>>  --8<---cut here---end--->8--
>>
>>
>>
>>
>> Now as write this, I found I could as well use a bbdb link and come to
>> similar results...
>>
>> :-(
>>
>>
>>  Sebastian
>>
___
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] how difficultwould it be to support zotero in org?

[Christian Moe]

On 9/3/10 10:55 PM, Matt Price wrote:

export Zotero to slightly tweaked
 BibTeX, and insert
with RefTeX's amazingly cool reference-insertion interface
(another genius piece of work by Carsten).

i'm getting nearly convinced to go this route.  May I ask, do you use
reftex from within org?  I'm not quite sure on how that would wok (but
also I'm not that familiar w/ the latex parts of the documentation...).


Hi,

You need to add a few lines to .emacs to make RefTex work with Org, 
described here:


http://www.mfasold.net/blog/2009/02/using-emacs-org-mode-to-draft-papers/

(scroll down to "References")

Raw latex citations like \cite{Smith2010} work fine.

If you want a more elaborate and Org-like way of doing it, here is one 
way of doing it with custom link types:


http://article.gmane.org/gmane.emacs.orgmode/2406/match=bibliography

I'm experimenting with some refinements, will post them here eventually.

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] Mobile mode sync problems

[Jing Su]

Dear all,

I just tried the MobileOrg on an iPhone 4 and a desktop (Windows 7 Home) via
Dropbox, and found the following problems. Most likely it's due to my wrong
configurations. Would someone kindly help me out please? The version of
Org-mode is 6.33x, and Emacs 23.2.1.

1. When ``org-mobile-push'', windows asks me to select a program to open the
.org files one by one before any file can be copied. I assume that it is not
what is supposed to happen?
2. After pushing, I did not find the ``agendas.org'' files created. All .org
files were copied into the Dropbox folder, and the index.org and
mobileorg.org files were created.
3. On the iP side, the agenda is, of coz, empty.
4. After changing the status of a task on the iP side, I can find the change
is clearly and accurately listed in the ``flagged.org'' file in my desktop
folder, but the ``org-mobile-pull'' does nothing, i.e., the local .org file
on my desktop is not synchronized.

Thank you very much for your help!

Jing
___
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] [PROPOSAL] Seemless editing of Babel Blocks

[Jambunathan K]

Eric

>
> I've just pushed up an implementation of the functionality described at
> the link above, see [1] for examples and details.
>

> Footnotes: 
> [1]  
> http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>

I have pulled your changes and examined it. Some commets:

Comment #1: Org Manual

> Org Manual - Section 14.8.2.7 comments

> org - Include text from the original org-mode file which preceded the
> code block as a comment which precedes the tangled code.

I suggest the following wording - 

"Include text from the org-mode file as a comment. 

 The text is picked from the leading context of the tangled code and is
 limited by the nearest headline or source block as the case may be."

Comment #2: Perceived gaps

In my original case,

1. Tangling happens in-place.

   The source and target buffers are one and the same only their major
   made changes. i.e., it is destructive. Think of 'replace-region' ...

2. There is no lossage.

   I can tangle to elisp-mode and untangle it to org-mode without any
   round-trip losses.

   With your changes, the following are lost - the 'trailing' text and
   the 'stars' in the headline.


That said, I have upgraded my request to a generic API (see attachment)
and I am not too particular about my original use-case (which I agree as
'contrived', 'drastic' and 'one-off')

Jambunathan K.

Attachments: This for the benefit of the list. 

I had accidentally unicast the reply. My recent transition to gnus has
made me very clumsy.

From: Jambunathan K 
To: "Eric Schulte" 
Subject: Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks
References: <4c45923...@gmail.com> <87k4opu5fk@gmail.com>
<81hbivx88y@gmail.com> <8139ueykvc.fsf...@gmail.com>
<878w3j1zos@stats.ox.ac.uk> <81k4n13mww@gmail.com>
<87r5h9czxf@gmail.com>
X-Draft-From: ("nntp+news.gmane.org:gmane.emacs.orgmode" 29790)
Date: Sun, 05 Sep 2010 14:28:16 +0530
In-Reply-To: <87r5h9czxf@gmail.com> (Eric Schulte's message of "Sat, 04
Sep 2010 09:04:03 -0600")
Message-ID: <81d3ssva6v@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (windows-nt)
--text follows this line--

jambu> How about providing user-accessible tapping points within
jambu> 'org-babel-map-src-blocks' (or a variation thereof) that would
jambu> enable me have a custom command in my .emacs.
jambu>
jambu> For the sake of record, my suggestion is very closely related to
jambu> what is discussed here.
jambu>
jambu> 
http://eschulte.github.com/babel-dev/PROPOSED-tangle-entire-org-mode-file-in-comments.html

Eric> I've just pushed up an implementation of the functionality
Eric> described at the link above, see [1] for examples and details.
Eric>
Eric> Is this sufficient to satisfy the need you were addressing?  If
Eric> not how could it be improved?

Eric> Footnotes: 
Eric> [1]  
http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html

I am making a request for an API from BABEL core which roughly parallels
org's org-map-entries.

Using this API a user should be able to 'traverse' babel and non-babel
blocks within a given scope (region, buffer), examine the local state
(say a tag or a user-defined property on a subtree), provide a verdict
on it's inclusion (yes I want it, no skip it) or possibly return a
transformed custom content (as a list).

'org-babel-map-src-blocks' has the skeletal structure for this API. All
it needs is some minimal tinkering to take on a more user-pluggable
form.

The proposed API would make UseCase-1 and UseCase-2 possible.

UseCase-1: 
http://article.gmane.org/gmane.emacs.orgmode/28823

Section-6 provides an illustration.
Section-5 helps one visualize the essentials of the propsed API.

a) org-to-org-src-view => potential consumer of the proposed API.
b) beg-org, end-org, beg-babel, end-babel => strategic 'points' of
   user-interest.
c) body, body1 => Hooks for user

UseCase-2: Tangling with custom pragmas.
http://article.gmane.org/gmane.emacs.orgmode/29805

Additional Note: Thinking out loud here (aka contrived, over-the-top
requirement). 

A user might want to override the in-buffer babel-control parameters
while tangling or execution.

Think of this scenario, I would like to tangle but with comments and
line nos as a one-off (say for circulating to my colleagues). The
in-buffer 'static/default' settings suppresses comments. I couldn't be
bothered to edit the in-buffer settings just for this one-off case. Is
there a possible way I can achieve this?

Jambunathan K.



___
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] Confused about mobileorg setup

[Ning Bao]

What I want to achieve is that upload many (50+) org files to my iphone via
dropbox. These org files are interlinked by file: links.

I am confused about how to set up MobileOrg.

Do I have to define the variable org-mobile-files in my .emacs, in order to
sync all my org files?

Or, what I need to do is to create a index.org in my "org-directory" folder
which contains file: links to all my org files?

Best regards,


Ning






On org-mode documentation:

B.2 Pushing to MobileOrg

This operation copies all files currently listed in org-mobile-files to the
directory org-mobile-directory. By default this list contains all agenda
files (as listed in org-agenda-files), but additional files can be included
by customizing org-mobiles-files. File names will be staged with path
relative to org-directory, so all files should be inside this directory.


On MobileOrg Documentation:

What files are transferred?

Your index.org file is fetched, then any files it links to are fetched, and
so on. For example, in the following case, 4 .org files will be
transferred: index.org, first.org, second.org and third.org. You may notice
third.org is linked to from two different places, but it is only downloaded
once.

*Contents of index.org:*

* [[file:first.org][An Org file I like]]
* [[file:second.org][Another Org file I like]]
  This is a [[file:third.org][link]] in the body text.

*Contents of first.org:*

* Some text
* [[file:third.org][Link to third.org]]
___
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] Speed keys

[Jambunathan K]

Carsten Dominik  writes:

> On Sat, Sep 4, 2010 at 10:13 PM, Jambunathan K
>  wrote:
>> One of the problems with C-c C-v prefix is that I tend to forget it if I
>> revisit Babel say after a week's time. (Not nitpicking here!). The
>> reason is that I simply couldn't contrive a convenient menemonic that
>> would make me recollect C-v.
>
>
> visit   (do something with the code snippets)

I would go with the first suggestion but with a slight modification.

visit   (this command makes me visit the Org Manual all the time)

:-)

Jambunathan K.



___
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] Adding entries to Google calendar

[Eric S Fraga]

On 4 Sep 2010 21:49:25 +0200, "Sven Bretfeld"  wrote:
> 
> Hi Eric
> 
> Eric S Fraga  writes:
> 
> > I'm not sure what you mean about complete.  It requires you to have
> > installed the Google command line tools (googlecl from Google Code).
> > However, this emacs lisp code is not what I would call full-featured
> > ;-)
> 
> There were several problems, most of which I have solved by now. First,
> I didn't set org-agenda-diary-file. So, calling "i" from an agenda-view
> merely opened the default diary file. That's why I wondered when
> exactly the advice comes into play. (Therefore I suspected the code to
> be possibly incomplete -- sorry, my fault.)

ah!  yes, the code is complete but the instructions are not.

> Now, the principle procedure works. Entries show up in Google after I
> added them with org-agenda-diary-entry. 
> 
> There is one thing left. You have structured the shell-command according
> to the American GoogleCL syntax. That's not working with the German
> locale. For a German GoogleCalendar the only syntax I found working is:

[...]

> Alas, there seems no description of the possible syntactical variants
> available on the web. 

Yes, Google do not appear to be very forthcoming with their parsing
algorithms.  I had to do a lot of trial and error, especially to
support block entries, and I think the result is fragile at best.

> So I did try-and-error: with and without the "am"
> and "um", with the English "on", with ISO formated dates etc etc. Except
> the above structure 'text am date um time' no combination works.
> 
> I fear, there are only two solutions:
> 
>   1. As a workaround I have set my GoogleCalendar to the American
>  locale. With that everything works fine.
> 
>   2. We have to isolate the time of day from the diary-entry as a
>  further variable (not as part of the variable "text"), so that
>  Germans can format the command correctly. Can you help me with
>  that?

I this moment (swamped with a project application), all I can suggest
is you look at org's time parsing codes for handling new agenda
entries.  The text must be parsed somewhere...  If you use the same
code within the advice, you should be able to pick off the times.

I'll add this to my todo list but I won't get a chance to play anytime
soon unfortunately.

> > However, the mechanism is there to support hooking into capture
> > specifically and possibly into org-time-stamp or org-schedule, say. 
> 
> I have tried to work out an advice to org-time-stamp and/or
> org-remember-finish today. But my Lisp is too weak. I couldn't figure
> out how to grab the data.

Maybe post what you did to this list and somebody might be able to
help?

> > I don't use Google calendar for scheduled tasks or deadlines so the
> > latter don't matter to me; I use it for appointments and my work flow
> > is that I always bring up the agenda view to see if my time is free
> > before making the appointment.
> 
> That's also my work flow, except of using org-remember "k-r" instead of
> "i". I like to have everything in one org-file. But I can get used to
> keep my appointments in a separate diary file. I can refile them to the
> appropriate places during the "weekly review" which, then, ends with the
> upload of a new ics file.

Can the diary file not be your all-in-one org file?
-- 
Eric S Fraga
GnuPG: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D
___
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] Bounce: Bug in iCal export?

[Guy Wiener]

Hello everyone,
Sorry for bouncing, but I got no response, and this behavior seems to me
like a bug,

I encountered the following weird behavior: When I set the option to
#+OPTIONS: tags:nil, and export an org file to an iCal file, the tag part of
the heading is still included in the description. E.g.:

#+OPTIONS: tags:nil
* TODO do this  :tag:

Is exported as:

BEGIN:VTODO
SUMMARY:do this  :tag:
END:VTODO

Beside being redundant, it also makes the entry in a calendar application
ugly.

What I want is to see the summary without the whitespace and tag part. Can
this behavior be configured or patched somehow?

Thanks,
  Guy Wiener
___
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] Confused about mobileorg setup

[Richard Moreland]

Hi Ning,

You are right that the documentation is a bit confusing there.  The
Org-mode docs describe the right way for you to proceed: define the
files you'd like to have transferred in org-agenda-files or
org-mobile-files.  This tells org-mobile-push which files to copy from
your local Org directory to Dropbox.

You should also be able to do:

(setq org-mobile-files (quote ("~/org")))

to have all .org files in a directory added to the list.

The MobileOrg docs are explaining that MobileOrg will only download
files referenced by another file.  In most cases this is useless
information, because if you list them all in org-mobile-files, they
will all be linked to from index.org and therefore all synced from
Dropbox to your phone.  I am working on some updated that I hope will
make it more clear.

Hope this helps,
Richard

On Sun, Sep 5, 2010 at 4:05 AM, Ning Bao  wrote:
> What I want to achieve is that upload many (50+) org files to my iphone via
> dropbox. These org files are interlinked by file: links.
> I am confused about how to set up MobileOrg.
> Do I have to define the variable org-mobile-files in my .emacs, in order to
> sync all my org files?
> Or, what I need to do is to create a index.org in my "org-directory" folder
> which contains file: links to all my org files?
> Best regards,
>
> Ning
>
>
>
>
>
> On org-mode documentation:
>
> B.2 Pushing to MobileOrg
>
> This operation copies all files currently listed in org-mobile-files to the
> directory org-mobile-directory. By default this list contains all agenda
> files (as listed in org-agenda-files), but additional files can be included
> by customizing org-mobiles-files. File names will be staged with path
> relative to org-directory, so all files should be inside this directory.
>
> On MobileOrg Documentation:
>
> What files are transferred?
>
> Your index.org file is fetched, then any files it links to are fetched, and
> so on. For example, in the following case, 4 .org files will be
> transferred: index.org, first.org, second.org and third.org. You may
> noticethird.org is linked to from two different places, but it is only
> downloaded once.
>
> Contents of index.org:
>
> * [[file:first.org][An Org file I like]]
> * [[file:second.org][Another Org file I like]]
>   This is a [[file:third.org][link]] in the body text.
>
> Contents of first.org:
>
> * Some text
> * [[file:third.org][Link to third.org]]
>
> ___
> 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] Mobile mode sync problems

[Greg Troxel]

Jing Su  writes:

> I just tried the MobileOrg on an iPhone 4 and a desktop (Windows 7 Home) via
> Dropbox, and found the following problems. Most likely it's due to my wrong
> configurations. Would someone kindly help me out please? The version of
> Org-mode is 6.33x, and Emacs 23.2.1.

You didn't post your config.

  (setq org-directory "~/ORG")
(setq org-mobile-directory "/ssh:foo.example.com:/usr/home/gdt/ORG")
  (setq org-mobile-inbox-for-pull
(concat org-directory "/from-mobile.org"))

is enough for me.

(I don't use Dropbox, but instead have my own webdav server.)

It sounds like you might be having a windows problem.


pgpHr6z9nvVaq.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: Setting org-agenda-time-grid: My day starts at midnight

[Memnon Anon]

Bastien  writes:
> Please pull again, this should be fixed now...

Still problem here.

Please try this:

0. Put attached 2 files into ~
1. `emacs -Q ~/minimal.el'
2. Adjust path to org-mode git dir and Eval Buffer minimal.el
3. Try 'C-c a a'
-> It fails for me
4. Uncomment `org-agenda-add-time-grid-maybe' in minimal.el
5. Eval Buffer
6. Try `C-c a a'
-> It works for me

If you do it not today, reschedule item1 in test.org to $today.

Memnon

Tested with: 
Org-mode version 7.01trans (release_7.01h.441.g798a78)
Last commit: commit 798a78fe06daf75bdbc2031a8f49edadd30612e1
 Author: Dan Davison 
 Date:   Sat Sep 4 13:36:48 2010 -0400
"GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-08-14 on raven, modified by Debian"



minimal.el
Description: minimal.el


test.org
Description: test.org
___
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] [PROPOSAL] Seemless editing of Babel Blocks

[Dan Davison]

Jambunathan K  writes:

>
> jambu> How about providing user-accessible tapping points within
> jambu> 'org-babel-map-src-blocks' (or a variation thereof) that would
> jambu> enable me have a custom command in my .emacs.
> jambu>
> jambu> For the sake of record, my suggestion is very closely related to
> jambu> what is discussed here.
> jambu>
> jambu> 
> http://eschulte.github.com/babel-dev/PROPOSED-tangle-entire-org-mode-file-in-comments.html
>
> Eric> I've just pushed up an implementation of the functionality
> Eric> described at the link above, see [1] for examples and details.
> Eric>
> Eric> Is this sufficient to satisfy the need you were addressing?  If
> Eric> not how could it be improved?
>
> Eric> Footnotes: 
> Eric> [1]  
> http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>
> I am making a request for an API from BABEL core which roughly parallels
> org's org-map-entries.
>
> Using this API a user should be able to 'traverse' babel and non-babel
> blocks within a given scope (region, buffer), examine the local state
> (say a tag or a user-defined property on a subtree), provide a verdict
> on it's inclusion (yes I want it, no skip it) or possibly return a
> transformed custom content (as a list).
>
> 'org-babel-map-src-blocks' has the skeletal structure for this API. All
> it needs is some minimal tinkering to take on a more user-pluggable
> form.

> The proposed API would make UseCase-1 and UseCase-2 possible.
>
> UseCase-1: 
> http://article.gmane.org/gmane.emacs.orgmode/28823
>
> Section-6 provides an illustration.
> Section-5 helps one visualize the essentials of the propsed API.
>
> a) org-to-org-src-view => potential consumer of the proposed API.
> b) beg-org, end-org, beg-babel, end-babel => strategic 'points' of
>user-interest.
> c) body, body1 => Hooks for user

Hi Jambunathan,

I assume that beg-babel and end-babel are the start and end of the
current code block. What exactly are beg-org and end-org here?

>
> UseCase-2: Tangling with custom pragmas.
> http://article.gmane.org/gmane.emacs.orgmode/29805
>
> Additional Note: Thinking out loud here (aka contrived, over-the-top
> requirement). 
>
> A user might want to override the in-buffer babel-control parameters
> while tangling or execution.
>
> Think of this scenario, I would like to tangle but with comments and
> line nos as a one-off (say for circulating to my colleagues). The
> in-buffer 'static/default' settings suppresses comments. I couldn't be
> bothered to edit the in-buffer settings just for this one-off case. Is
> there a possible way I can achieve this?

Many of the core org-babel functions accept an optional argument named
`info'. This is a data structure which contains all the relevant
settings: language, the body, the header args, etc. If this argument is
provided, then no attempt is made to obtain the settings from the
buffer. So the way to do this is to construct your own info data
structure and then pass it to the org-babel function you are using
(e.g. org-babel-execute-src-block).

Typically, the info structure is created from the buffer using
org-babel-get-src-block-info. See the docstring of that function for a
definition of the data structure.

As an example of on-the-fly construction of an info data structure (and
thus a "virtual" code block that doesn't exist in any buffer), see the
way Eric implemented #+lob calls in `org-babel-lob-execute' (it's quite
clever).

Also note in those functions that there is a useful function
`org-babel-merge-params': In org-babel code, "params" generally means an
association list of header argument (argument, value)
pairs. `org-babel-merge-params' allows you to construct the params alist
from a variety of different sources (the buffer settings, and your own
settings): later arguments have priority over earlier ones. Grepping for
org-babel-merge-params in the code shows some examples of using it to
construct the "params" part of the "info" structure, e.g.:

ob-ref.el:162:  (setq params (org-babel-merge-params params args '((:results . 
"silent"
ob-table.el:119:  (org-babel-merge-params '((:results . 
"silent")) params


Based on a very quick look, it seems that tangle is gloing to be
slightly different from execute. For tangle, you might want to use a
let-binding to bind a temporary value of org-babel-default-header-args,
constructed using org-babel-merge-params as on line 146 of ob-tangle.el.

Dan



>
> Jambunathan K.
>
>
>
> ___
> 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: Orgmode: exporter for taskjuggler

[Bastien]

Markus Heller  writes:

> After a lot of googling, I actually managed to get TJ2 to run on my box,
> but it's a pain ...  TJ3 would certainly make life easier.

Same here.  

Looking forward support of tj3 in org-taskjuggler.el...

Thanks Christian!

-- 
 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] horiontal alignment of tables in latex export?

[Bastien]

Matt Price  writes:

> See org-export-latex-tables-centered:
>
> (defcustom org-export-latex-tables-centered t
>  "When non-nil, tables are exported in a center environment."
>  :group 'org-export-latex
>  :type 'boolean)
>
> this was the solution!  thanks so much.

I added a FAQ entry for this.

-- 
 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

[Orgmode] Bug? org.el:org-open-at-point

[Achim Gratz]

It seems like news: links are always sent to the browser and this
definition is hiding a later invocation of GNUS:

---
 ((member type '("http" "https" "ftp" "news"))
  (browse-url (concat type ":" (org-link-escape
path org-link-escape-chars-browser
 ;;;
 ;;; some more lines
 ;;;
 ((string= type "news")
  (require 'org-gnus)
  (org-gnus-follow-link path))
---

Additionally, if I take out "news" from the first bit of code and follow
a news: link, the code that supposedly opens news links in GNUS doesn't
seem to work on my system (gmane is a foreign server in GNUS here, but
that doesn't seem to be the reason).


Achim.


___
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] How can I search keywords in my org project?

[Bastien]

Hi Water,

Water Lin  writes:

> So, here somes the problem. When I try to find something by keywords or
> something else, what can I do? Is there any embeded search engine for
> this work?

>From the agenda:

  M-x org-agenda RET s

You can also use `occur-tree' as a custom agenda view:

  http://www.gnu.org/software/emacs/manual/html_node/org/Storing-searches.html

> Or Can I use other way in Emacs itself?

Go to your directory using dired, then M-x grep-find RET.

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] Bug? org.el:org-open-at-point

[David Maus]

Achim Gratz wrote:

>It seems like news: links are always sent to the browser and this
>definition is hiding a later invocation of GNUS:

Indeed, this is an inconsistency.  The right way would be for org-gnus
(and other mail readers, like org-wl) to register the link type.


>---
>((member type '("http" "https" "ftp" "news"))
> (browse-url (concat type ":" (org-link-escape
>   path org-link-escape-chars-browser
> ;;;
> ;;; some more lines
> ;;;
>((string= type "news")
> (require 'org-gnus)
> (org-gnus-follow-link path))
>---

>Additionally, if I take out "news" from the first bit of code and follow
>a news: link, the code that supposedly opens news links in GNUS doesn't
>seem to work on my system (gmane is a foreign server in GNUS here, but
>that doesn't seem to be the reason).

What syntax did you try?  IIRC `org-gnus-follow-link' expects a /Gnus/
link in path, but RFC5538 ("The 'news' and 'nntp' URI Schemes ")[1] has a
different definition that must be normalized to a org-gnus.link.

I'll see to provide a patch to org-gnus.el to handle news: and nntp:
links according to the specs.

Best,
  -- David

[1] http://tools.ietf.org/html/rfc5538
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de


pgpO1E4M7sOhR.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] Re: "Interactive" Search in Agenda

[Bastien]

Markus Heller  writes:

> Yes, that would be nice.  What would it look like then?  Like this:
>
> 1. Hit C-c a
> 2. Hit `m'
> 3. Type +S and then hit TAB which expands to +Sample
> 4. Continue with ="S0002"
>
> Is this what you're thinking about?

Yes.  But I haven't looked into the details now, so I don't know how
hard it is to implement this.

-- 
 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: [PATCH] inside table, delete-backward-char must not insert spaces when overwrite mode is on

[Bastien]

Achim Gratz  writes:

>> If I understand it correctly, it does not change the current visual
>> behavior of `org-delete-backward-char', it just skips the unnecessary
>> step of inserting a whitespace when overwrite-mode is on.
>>
>> Is that so?
>
> That was the plan, yes. :-)
> Hopefully it does that (and just that).

Okay, I'll apply this as soon as the patchwork server is back.

Thanks,

> [Please do not Cc: me, thanks.  I read the list with GNUS and don't need
> another copy in my inbox.]

Okay...

(setq nnmail-treat-duplicates 'delete)

:)

-- 
 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] horiontal alignment of tables in latex export?

[Matt Price]

On Sun, Sep 5, 2010 at 1:26 PM, Bastien  wrote:

> Matt Price  writes:
>
> > See org-export-latex-tables-centered:
> >
> > (defcustom org-export-latex-tables-centered t
> >  "When non-nil, tables are exported in a center environment."
> >  :group 'org-export-latex
> >  :type 'boolean)
> >
> > this was the solution!  thanks so much.
>
> I added a FAQ entry for this.\

thanks bastien, should have done that myself, somewhat harried atthe moment.
m


>
> --
>  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] BUG ??? Cannot export custom link type to ASCII :-(

[Bastien]

Hi Sebastian,

Sebastian Rose  writes:

> Hmmm  this seems so deliberate...  For bbdb links this even seems to
> make sense...  But how could I avoid this "footnote like" behaviour?

Actually, I've wished for a long time that we can have a *real* footnote
behavior for links when exporting to ASCII.

For example:

  This [[http://orgmode.org][Org]] thingy is great.

Would be exported to:

  This Org¹ thingy is great.

  ¹ http://orgmode.org

I'm putting this on my TODO list...

-- 
 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] Bounce: Bug in iCal export?

[Bastien]

Guy Wiener  writes:

> Sorry for bouncing, but I got no response, and this behavior seems to me like 
> a
> bug,

It is -- fixed now in the repo.

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

[Orgmode] Re: Bug? org.el:org-open-at-point

[Achim Gratz]

David Maus  writes:

> What syntax did you try?  IIRC `org-gnus-follow-link' expects a /Gnus/
> link in path, but RFC5538 ("The 'news' and 'nntp' URI Schemes ")[1] has a
> different definition that must be normalized to a org-gnus.link.

I tried news:gmane.emacs.orgmode (incomplete, I know), but any other
link with authority would produce the same result: GNUS tries to enter a
group with the literal path as specified in the link and gets stuck.

---
   9:*nntp+news.gmane.org:gmane.emacs.orgmode
 K *: //news.gmane.org/gmane.emacs.orgmode
---

The correct path syntax suggested by GNUS to give to
gnus-group-jump-to-group is nntp+news.gmane.org:gmane.emacs.orgmode, but
that still doesn't open the Summary buffer and gives no further error
message.  Browsing around in org-gnus.el suggests that news: links
should probably not go through that function in org-gnus.el since it
registers it's own gnus: handler just for that.


Achim.


___
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: Automatically move completed TODO items and checkboxes to another file

[Bastien]

Hi Michael,

Michael Hoffman <9qobl2...@sneakemail.com> writes:

> Well, the commands:
>
> C-u C-c C-c
> C-x C-x
> C-c *
>
> convert the checkboxes to headings but eliminate the hierarchy.
>
> I've also tried regex-searching for something like "^   - \[ \]" -> "***
> TODO" but it's not foolproof since the number of leading spaces doesn't
> always have something to do with the level of the previous header.

I see -- I'm not familiar enough with the new list implementation to
look into this now... 

Best,

-- 
 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: Setting org-agenda-time-grid: My day starts at midnight

[Bastien]

Memnon Anon  writes:

> Bastien  writes:
>> Please pull again, this should be fixed now...
>
> Still problem here.

Fixed again - thanks for the detailed feedback!

-- 
 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] Bounce: Bug in iCal export?

[David Maus]

Bastien wrote:
>Guy Wiener  writes:

>> Sorry for bouncing, but I got no response, and this behavior seems to me 
>> like a
>> bug,

>It is -- fixed now in the repo.

Uhh... Not really :/ It will still happens for TODO entries and
instead of `replace-regexp-in-string' we could simply call
`org-get-heading' with the NO-TAGS option.

Do you mind if I revert the commit and check in a better solution?

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


pgpwcjuRMOfiC.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] Beamer column alignment

[John Hendy]

Hi,


Found this: http://osdir.com/ml/emacs-orgmode-gnu/2009-12/msg00238.html

Does the referenced BEAMER_envargs option of:


:BEAMER_envargs: [op-for-block] c[opt-for-column-env] C[opt-for-
columns-env]


actually work? The discussion seems like it might have taken place as Beamer
support was being decided and so I'm not sure if it made it or not.

Can anyone verify this works? Am I doing it wrong?

*** heading
:PROPERTIES:
:BEAMER_col: 0.45
:BEAMER_env: ignoreheading
:BEAMER_envargs: c[opt-for-column-env]
:END:



John
___
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: Beamer column alignment

[John Hendy]

Hmmm. On a fluke I found this as well (good to know in general!):
http://orgmode.org/manual/Beamer-class-export.html

This *kind* of works,
though perhaps I should specify that I was hoping for horizontal alignment,
not vertical. When I set c[c] on column 1, for some reason column 2 jumps
way down toward the bottom of the page...


John

On Sun, Sep 5, 2010 at 2:33 PM, John Hendy  wrote:

> Hi,
>
>
> Found this: http://osdir.com/ml/emacs-orgmode-gnu/2009-12/msg00238.html
>
> Does the referenced BEAMER_envargs option of:
>
> 
> :BEAMER_envargs: [op-for-block] c[opt-for-column-env] C[opt-for-
> columns-env]
> 
>
> actually work? The discussion seems like it might have taken place as
> Beamer support was being decided and so I'm not sure if it made it or not.
>
> Can anyone verify this works? Am I doing it wrong?
>
> *** heading
> :PROPERTIES:
> :BEAMER_col: 0.45
> :BEAMER_env: ignoreheading
> :BEAMER_envargs: c[opt-for-column-env]
> :END:
>
>
>
> John
>
___
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: Automatically move completed TODO items and checkboxes to another file

[Nicolas Goaziou]

Hello,
> Michael Hoffman writes:

> I've also tried regex-searching for something like "^ - \[ \]" ->
> "*** TODO" but it's not foolproof since the number of leading spaces
> doesn't always have something to do with the level of the previous
> header.

It looks like you're looking for `org-list-make-subtree' (C-c C-*) and
then replacing [CBON] with DONE and [CBOFF] with TODO.

If it's something else, could you explain it with an example?

Regards,

-- 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] [Squashed] (was: Setting org-agenda-time-grid: My day starts at midnight)

[Memnon Anon]

Bastien  writes:
> Memnon Anon  writes:
>> Still problem here.
> Fixed again - thanks for the detailed feedback!

Yes! 
Confirmed, it works.
Thank *you* for persisting ;).

Memnon




___
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] Bounce: Bug in iCal export?

[Bastien]

David Maus  writes:

> Uhh... Not really :/ It will still happens for TODO entries 

Why?

> and
> instead of `replace-regexp-in-string' we could simply call
> `org-get-heading' with the NO-TAGS option.

Yep.

> Do you mind if I revert the commit and check in a better solution?

Absolutely not!  Thanks for asking

-- 
 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

[Accepted] [Orgmode] Use `C-c C-x _' for interactively calling `org-timer-stop'

[Bastien Guerry]

Patch 255 (http://patchwork.newartisans.com/patch/255/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C8762yn6gq0.fsf%40gnu.org%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [Orgmode] Use `C-c C-x _' for interactively calling `org-timer-stop'
> Date: Fri, 03 Sep 2010 01:19:35 -
> From: Bastien 
> X-Patchwork-Id: 255
> Message-Id: <8762yn6gq0@gnu.org>
> To: emacs-orgmode@gnu.org
> 
> Unless I missed something, `org-timer-stop' has no keybinding yet.
> I propose to use `C-c C-x _'.
> 
> Is that okay for everyone?
> 
> 
> diff --git a/lisp/org.el b/lisp/org.el
> index fc44fc7..01da980 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -16383,6 +16383,7 @@ BEG and END default to the buffer boundaries."
>  (org-defkey org-mode-map "\C-c\C-x."'org-timer)
>  (org-defkey org-mode-map "\C-c\C-x-"'org-timer-item)
>  (org-defkey org-mode-map "\C-c\C-x0"'org-timer-start)
> +(org-defkey org-mode-map "\C-c\C-x_"'org-timer-stop)
>  (org-defkey org-mode-map "\C-c\C-x,"'org-timer-pause-or-continue)
>  
>  (define-key org-mode-map "\C-c\C-x\C-c" 'org-columns)
> 

___
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

[Accepted] [Orgmode] inside table, delete-backward-char must not insert spaces when overwrite mode is on

[Bastien Guerry]

Patch 245 (http://patchwork.newartisans.com/patch/245/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C201008271956.43528.Stromeko%40stromeko.net%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [Orgmode] inside table,
>   delete-backward-char must not insert spaces when overwrite mode is on
> Date: Fri, 27 Aug 2010 22:56:43 -
> From: Achim Gratz 
> X-Patchwork-Id: 245
> Message-Id: <201008271956.43528.strom...@stromeko.net>
> To: emacs-orgmode@gnu.org
> 
> * lisp/org.el (org-delete-backward-char): check for nil overwrite-mode before 
> inserting 
> spaces.
> 
> TINYCHANGE
> 
> There's probably a different/better way to do this, but this seemed the least 
> intrusive.
> This patch is in the public domain.
> 
> ---
> lisp/org.el |8 +---
>  1 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/lisp/org.el b/lisp/org.el
> index bc62633..41f35d4 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -16597,9 +16597,11 @@ because, in this case the deletion might narrow the 
> column."
>   (noalign (looking-at "[^|\n\r]*  |"))
>   (c org-table-may-need-update))
>   (backward-delete-char N)
> - (skip-chars-forward "^|")
> - (insert " ")
> - (goto-char (1- pos))
> + (if (not overwrite-mode)
> + (progn
> +   (skip-chars-forward "^|")
> +   (insert " ")
> +   (goto-char (1- pos
>   ;; noalign: if there were two spaces at the end, this field
>   ;; does not determine the width of the column.
>   (if noalign (setq org-table-may-need-update c)))
> 

___
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: [PATCH] inside table, delete-backward-char must not insert spaces when overwrite mode is on

[Bastien]

Bastien  writes:

>> That was the plan, yes. :-)
>> Hopefully it does that (and just that).
>
> Okay, I'll apply this as soon as the patchwork server is back.

Done.

-- 
 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

[Orgmode] A few stats and figures about org/worg and the mailing list

[Bastien]

http://orgmode.org/worg/org-worg-stats.php
http://orgmode.org/worg/org-mailing-list.php#sec-3

Thanks to Eric Schulte for write the babel file which 
produced the commits stats (I'll update this graph from
time to time.)

-- 
 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] Bounce: Bug in iCal export?

[David Maus]

Bastien wrote:
>David Maus  writes:

>> Uhh... Not really :/ It will still happens for TODO entries

>Why?

The headline information is fetched again (?) if
`org-icalendar-include-todo' is non-nil (line 474) and Org creates a
VTODO entity.  Looks like the iCal export function could use some
refactoring -- I stumbled on this by accident because calling
`org-get-headline' with the NO-TAGS option didn't solve the problem
for a iCal entry with a TODO state and a tag.

>> Do you mind if I revert the commit and check in a better solution?

>Absolutely not!  Thanks for asking

Fine.  My first git revert \o/

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


pgpNzBpWZNloL.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: [babel] ledger tutorial on Worg

[Sébastien Vauban]

Hi Eric,

"Eric Schulte" wrote:
> Sébastien Vauban  writes:
>
>> Hi Eric(s),
>>
>
> Hi Seb,
>
> [...]
>>
>> 1. I find it weird to have all the parameters of =:cmdline= not enclosed
>>between quotes. What should be the best option, here?  That was a subject,
>>long ago, on Org-Babel: to quote or not to quote...
>>
>
> I don't know that this was ever explicitly discussed, I believe that the
> no-quoting behavior may have simply fallen out of the initial
> implementation.  I'd certainly like to hear other people's opinions on
> this, but I've personally enjoyed not having to place quotes in every
> instance.

In december 2009, I wrote:

"I'm a bit confused (as you may have seen in my last posts) about when we
do have to quote strings and when we do have to avoid doing it. Would you
have a one-liner explanation about when we have to use quotes?"

See http://www.mail-archive.com/emacs-orgmode@gnu.org/msg20265.html for
contextual information.

I remembered "you" (Dan or you) answered it somehow, but it must have been
(around that same period) in another thread. Though, I don't find pointers
anymore...

Question is more: is it clear to mix parameters names (such as =:cmdline=) and
long values which are unquoted (such as =registry unknown credit-card= and
many much more options)?

Shouldn't we properly begin and end where the given value is?


>> 2. When the evaluation produces no output, but had well produced output
>>before, shouldn't Babel have to delete the previously written results in
>>the Org buffer?
>
> This is a good point. Currently Babel just quits if it receives a nil
> result, but I think you're right that we should replace existing results
> when a nil result has been returned. I'll add this as PROPOSED to the babel
> task list.

I consider this kind of mandatory, for the sake of coherency, and to really
make use of Org-babel every time I want to run some shell commands (and change
them, eventually getting no results then).

Thanks a lot for everything you did and do for us.

Best regards,
  Seb

-- 
Sébastien Vauban


___
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: Capture abort: (void-function -mode)

[Sébastien Vauban]

Hi Noorul,

Noorul Islam wrote:
> 2010/9/3 Sébastien Vauban :
>> Hello,
>>
>> With git pull'ed yesterday eve, I now have this popping up when capturing 
>> some
>> text from Gnus:
>>
>> --8<---cut here---start->8---
>> Debugger entered--Lisp error: (error "Capture abort: (void-function -mode)")
>>  signal(error ("Capture abort: (void-function -mode)"))
>>  error("Capture abort: %s" (void-function -mode))
>>  (condition-case error (org-capture-put :template 
>> (org-capture-fill-template)) ((error quit) (if ... ...) (error "Capture 
>> abort: %s" error)))
>>  (cond ((equal entry "C") (customize-variable ...)) ((equal entry "q") 
>> (error "Abort")) (t (org-capture-set-plist entry) (org-capture-get-template) 
>> (org-capture-put :original-buffer orig-buf :annotation annotation :initial 
>> initial) (org-capture-put :default-time ...) 
>> (org-capture-set-target-location) (condition-case error ... ...) (if ... ... 
>> ... ...)))
>>  (let* ((orig-buf ...) (annotation ...) (initial ...) (entry ...)) (when 
>> (stringp initial) (remove-text-properties 0 ... ... initial)) (when (stringp 
>> annotation) (remove-text-properties 0 ... ... annotation)) (cond (... ...) 
>> (... ...) (t ... ... ... ... ... ... ...)))
>>  (cond ((equal goto ...) (org-capture-goto-target)) ((equal goto ...) 
>> (org-capture-goto-last-stored)) (t (let* ... ... ... ...)))
>>  org-capture(nil)
>>  call-interactively(org-capture nil nil)
>> --8<---cut here---end--->8---
>>
>> Any idea?
>
> Can you provide steps to re-produce this?

No, with some more use of it, I can tell it's not occurring every time.
Occurred a couple of times before I posted the above message. Not always, so.

Next time it occurs, I try to make it reproducible.

Though, I thought the message could give info to someone eventually having
played with that port of the code in the last days...


> Also which template are you using?

This one:

#+begin_src org
("No" "Org" entry
  (file+headline "~/Public/Notes-on-Org.txt" "Notes")
  "* %^{Title}
   :PROPERTIES:
   :Created: %U
   :END:

%i

>From %a"
:empty-lines 1)
#+end_src

Best regards,
  Seb

-- 
Sébastien Vauban


___
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: Value of `ispell-dictionary-alist' reset by `org-agenda-list'

[Sébastien Vauban]

Hi Noorul and everybody,

Noorul Islam wrote:
> 2010/9/3 Sébastien Vauban :
>> I still don't understand what's going on, but I've managed getting closer to 
>> a
>> long experienced problem in my Emacs: while I set the value of
>> =ispell-dictionary-alist= in the beginning of my =.emacs= file, it is reset
>> when calling =org-agenda-list=.

--8<---cut here---start->8---
(message "Value of `ispell-dictionary-alist' before `org-agenda-list'")
(edebug-print ispell-dictionary-alist)

(org-agenda-list)

(message "Value of `ispell-dictionary-alist' after `org-agenda-list'")
(edebug-print ispell-dictionary-alist)

(delete-other-windows)
--8<---cut here---end--->8---

>> Has anyone any idea on how to circumvent this?
>
> Since orgmode is using flyspell, looks like it is interfering with ispell.
>
> From flyspell.el
> ==
> (defun flyspell-mode-on ()
>   "Turn Flyspell mode on.  Do not use this; use `flyspell-mode' instead."
>   (ispell-set-spellchecker-params) ; Initialize variables and dicts alists
>   (setq ispell-highlight-face 'flyspell-incorrect)
>   ;; local dictionaries setup
>   (or ispell-local-dictionary ispell-dictionary
>   (if flyspell-default-dictionary
>   (ispell-change-dictionary flyspell-default-dictionary)))
> ==

Yes, but I don't understand why Org *would* (and did not write *does*, as it
still is not clear enough to me) setq the list of dictionaries...

Clearly a behavior to forbid!

Best regards,
  Seb

-- 
Sébastien Vauban


___
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] [PROPOSAL] Seemless editing of Babel Blocks

[Eric Schulte]

Hi Jambunathan,

Jambunathan K  writes:

> Eric
>
>>
>> I've just pushed up an implementation of the functionality described at
>> the link above, see [1] for examples and details.
>>
>
>> Footnotes: 
>> [1]  
>> http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>>
>
> I have pulled your changes and examined it. Some commets:
>
> Comment #1: Org Manual
>
>> Org Manual - Section 14.8.2.7 comments
>
>> org - Include text from the original org-mode file which preceded the
>> code block as a comment which precedes the tangled code.
>
> I suggest the following wording - 
>
> "Include text from the org-mode file as a comment. 
>
>  The text is picked from the leading context of the tangled code and is
>  limited by the nearest headline or source block as the case may be."
>

Thanks, I've made this change in the manual.

>
> Comment #2: Perceived gaps
>
> In my original case,
>
> 1. Tangling happens in-place.
>
>The source and target buffers are one and the same only their major
>made changes. i.e., it is destructive. Think of 'replace-region' ...
>
> 2. There is no lossage.
>
>I can tangle to elisp-mode and untangle it to org-mode without any
>round-trip losses.
>
>With your changes, the following are lost - the 'trailing' text and
>the 'stars' in the headline.
>
>
> That said, I have upgraded my request to a generic API (see attachment)
> and I am not too particular about my original use-case (which I agree as
> 'contrived', 'drastic' and 'one-off')
>

Great.  I've acted on your API request so hopefully that will supersede
the need for more drastic tangling extensions.

Thanks -- Eric

>
> Jambunathan K.
>
> Attachments: This for the benefit of the list. 
>
> I had accidentally unicast the reply. My recent transition to gnus has
> made me very clumsy.
>
> From: Jambunathan K 
> To: "Eric Schulte" 
> Subject: Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks
> References: <4c45923...@gmail.com> <87k4opu5fk@gmail.com>
>   <81hbivx88y@gmail.com> <8139ueykvc.fsf...@gmail.com>
>   <878w3j1zos@stats.ox.ac.uk> <81k4n13mww@gmail.com>
>   <87r5h9czxf@gmail.com>
> X-Draft-From: ("nntp+news.gmane.org:gmane.emacs.orgmode" 29790)
> Date: Sun, 05 Sep 2010 14:28:16 +0530
> In-Reply-To: <87r5h9czxf@gmail.com> (Eric Schulte's message of "Sat, 04
>   Sep 2010 09:04:03 -0600")
> Message-ID: <81d3ssva6v@gmail.com>
> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (windows-nt)
> --text follows this line--
>
> jambu> How about providing user-accessible tapping points within
> jambu> 'org-babel-map-src-blocks' (or a variation thereof) that would
> jambu> enable me have a custom command in my .emacs.
> jambu>
> jambu> For the sake of record, my suggestion is very closely related to
> jambu> what is discussed here.
> jambu>
> jambu> 
> http://eschulte.github.com/babel-dev/PROPOSED-tangle-entire-org-mode-file-in-comments.html
>
> Eric> I've just pushed up an implementation of the functionality
> Eric> described at the link above, see [1] for examples and details.
> Eric>
> Eric> Is this sufficient to satisfy the need you were addressing?  If
> Eric> not how could it be improved?
>
> Eric> Footnotes: 
> Eric> [1]  
> http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>
> I am making a request for an API from BABEL core which roughly parallels
> org's org-map-entries.
>
> Using this API a user should be able to 'traverse' babel and non-babel
> blocks within a given scope (region, buffer), examine the local state
> (say a tag or a user-defined property on a subtree), provide a verdict
> on it's inclusion (yes I want it, no skip it) or possibly return a
> transformed custom content (as a list).
>
> 'org-babel-map-src-blocks' has the skeletal structure for this API. All
> it needs is some minimal tinkering to take on a more user-pluggable
> form.
>
> The proposed API would make UseCase-1 and UseCase-2 possible.
>
> UseCase-1: 
> http://article.gmane.org/gmane.emacs.orgmode/28823
>
> Section-6 provides an illustration.
> Section-5 helps one visualize the essentials of the propsed API.
>
> a) org-to-org-src-view => potential consumer of the proposed API.
> b) beg-org, end-org, beg-babel, end-babel => strategic 'points' of
>user-interest.
> c) body, body1 => Hooks for user
>
> UseCase-2: Tangling with custom pragmas.
> http://article.gmane.org/gmane.emacs.orgmode/29805
>
> Additional Note: Thinking out loud here (aka contrived, over-the-top
> requirement). 
>
> A user might want to override the in-buffer babel-control parameters
> while tangling or execution.
>
> Think of this scenario, I would like to tangle but with comments and
> line nos as a one-off (say for circulating to my colleagues). The
> in-buffer 'static/default' settings suppresses comments. I couldn't be
> bothered to edit the in-buffer settings just for this one-off case. Is
> there a possible way I can achieve this?
>
> Jambunat

[Orgmode] Re: [BABEL] [PROPOSAL] Seemless editing of Babel Blocks

[Eric Schulte]

Hi,

Dan Davison  writes:

> Jambunathan K  writes:
>
>>
>> jambu> How about providing user-accessible tapping points within
>> jambu> 'org-babel-map-src-blocks' (or a variation thereof) that would
>> jambu> enable me have a custom command in my .emacs.
>> jambu>
>> jambu> For the sake of record, my suggestion is very closely related to
>> jambu> what is discussed here.
>> jambu>
>> jambu> 
>> http://eschulte.github.com/babel-dev/PROPOSED-tangle-entire-org-mode-file-in-comments.html
>>
>> Eric> I've just pushed up an implementation of the functionality
>> Eric> described at the link above, see [1] for examples and details.
>> Eric>
>> Eric> Is this sufficient to satisfy the need you were addressing?  If
>> Eric> not how could it be improved?
>>
>> Eric> Footnotes: 
>> Eric> [1]  
>> http://eschulte.github.com/babel-dev/DONE-tangle-entire-org-mode-file-in-comments.html
>>
>> I am making a request for an API from BABEL core which roughly parallels
>> org's org-map-entries.
>>
>> Using this API a user should be able to 'traverse' babel and non-babel
>> blocks within a given scope (region, buffer), examine the local state
>> (say a tag or a user-defined property on a subtree), provide a verdict
>> on it's inclusion (yes I want it, no skip it) or possibly return a
>> transformed custom content (as a list).
>>
>> 'org-babel-map-src-blocks' has the skeletal structure for this API. All
>> it needs is some minimal tinkering to take on a more user-pluggable
>> form.
>
>> The proposed API would make UseCase-1 and UseCase-2 possible.
>>
>> UseCase-1: 
>> http://article.gmane.org/gmane.emacs.orgmode/28823
>>
>> Section-6 provides an illustration.
>> Section-5 helps one visualize the essentials of the propsed API.
>>
>> a) org-to-org-src-view => potential consumer of the proposed API.
>> b) beg-org, end-org, beg-babel, end-babel => strategic 'points' of
>>user-interest.

I'll make a guess here that beg/end-org and the beginning and end of the
code block, and beg/end-babel are the beginning and end of the code
block?

This seems reasonable, and it's a minor change to let-bind all of the
relevant match-data points (like those 4 mentioned above) to temporary
variables which would then make them available to users of
ob-map-src-blocks.  I've just pushed up an enhanced ob-map-src-blocks
which implements the above.  I'll include the new docstring below [1]

>> 
>> c) body, body1 => Hooks for user
>

I don't know what you mean by hooks for the user.  When would these
hooks be run?

>
> Hi Jambunathan,
>
> I assume that beg-babel and end-babel are the start and end of the
> current code block. What exactly are beg-org and end-org here?
>
>>
>> UseCase-2: Tangling with custom pragmas.
>> http://article.gmane.org/gmane.emacs.orgmode/29805
>>
>> Additional Note: Thinking out loud here (aka contrived, over-the-top
>> requirement). 
>>
>> A user might want to override the in-buffer babel-control parameters
>> while tangling or execution.
>>
>> Think of this scenario, I would like to tangle but with comments and
>> line nos as a one-off (say for circulating to my colleagues). The
>> in-buffer 'static/default' settings suppresses comments. I couldn't be
>> bothered to edit the in-buffer settings just for this one-off case. Is
>> there a possible way I can achieve this?
>
> Many of the core org-babel functions accept an optional argument named
> `info'. This is a data structure which contains all the relevant
> settings: language, the body, the header args, etc. If this argument is
> provided, then no attempt is made to obtain the settings from the
> buffer. So the way to do this is to construct your own info data
> structure and then pass it to the org-babel function you are using
> (e.g. org-babel-execute-src-block).
>
> Typically, the info structure is created from the buffer using
> org-babel-get-src-block-info. See the docstring of that function for a
> definition of the data structure.
>
> As an example of on-the-fly construction of an info data structure (and
> thus a "virtual" code block that doesn't exist in any buffer), see the
> way Eric implemented #+lob calls in `org-babel-lob-execute' (it's quite
> clever).
>
> Also note in those functions that there is a useful function
> `org-babel-merge-params': In org-babel code, "params" generally means an
> association list of header argument (argument, value)
> pairs. `org-babel-merge-params' allows you to construct the params alist
> from a variety of different sources (the buffer settings, and your own
> settings): later arguments have priority over earlier ones. Grepping for
> org-babel-merge-params in the code shows some examples of using it to
> construct the "params" part of the "info" structure, e.g.:
>
> ob-ref.el:162:(setq params (org-babel-merge-params params args 
> '((:results . "silent"
> ob-table.el:119:  (org-babel-merge-params '((:results . 
> "silent")) params
>
>
> Based on a very quick look, it seems that tangle is gloing t

Re: [Orgmode] Line numbers in tangled source

[Eric Schulte]

Hi,

This isn't the first request for customizable comments in tangled code.
I've just implemented a first pass at this functionality, the variables
org-babel-tangle-comment-format-beg and
org-babel-tangle-comment-format-end now hold simple format string
specifying how the comments surrounding code blocks should be
constructed, see their documentation for more info.

As an example, the following specification should yield the results
you're after
#+begin_src emacs-lisp :results silent
  (setq org-babel-tangle-comment-format-beg "{-# LINE %start-line \"%file\" #-}"
org-babel-tangle-comment-format-end ""
org-babel-tangle-pad-newline)
#+end_src

Best -- Eric

aditya siram  writes:

> Yes I am aware of the comments argument but it is not what I was
> referring to. What I want is, if I had the following in a file called
> "Haskell.org" :
> * Root
> Root comment
> #+begin_src haskell :tangle Main.hs
>   test = length
>   main = print $ test [1,2,3]
> #+end_src
>
> I would like the following output in the tangled file Main.hs:
>
> {-# LINE 4 "Haskell.org" #-}
> test = length
> main = print $ test [1,2,3]
>
> The line that starts with {-# LINE ... #-} is a pragma that tells the
> compiler that this line corresponds to line 4 in Haskell.org and if
> there is an error it will point to that file and not to Main.hs.
>
> Can I take it that this functionality doesn't yet exist?
>
> -deech
>
>
> On Sat, Sep 4, 2010 at 8:21 AM, Eric Schulte  wrote:
>>
>> Hi,
>>
>> You can use the :comments header argument to include comments around
>> tangled code blocks indicating where the code block lives in the
>> original Org file.
>>
>> See [1] for information on the :comment header argument, and see [2] for
>> information on using header arguments in general.
>>
>> Best -- Eric
>>
>> aditya siram  writes:
>>
>> > Hi all,
>> > How do I get the org file line numbers in the tangled source? This way 
>> > error
>> > messages point to the org file.
>> >
>> > thanks ...
>> > -deech
>>
>> Footnotes:
>> [1]  http://orgmode.org/manual/comments.html#comments
>>
>> [2]  
>> http://orgmode.org/manual/Using-header-arguments.html#Using-header-arguments
>>

___
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] A few stats and figures about org/worg and the mailing list

[Sebastian Rose]

Bastien  writes:
> http://orgmode.org/worg/org-worg-stats.php
> http://orgmode.org/worg/org-mailing-list.php#sec-3
>
> Thanks to Eric Schulte for write the babel file which 
> produced the commits stats (I'll update this graph from
> time to time.)


This is so coool!

Reminders on the "biggest events" on this mailing list.
"POLL: the 40 variables project" ...

Wow!  Thanks 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] A few stats and figures about org/worg and the mailing list

[Erik Iverson]

On 09/05/2010 05:52 PM, Sebastian Rose wrote:

Bastien  writes:

http://orgmode.org/worg/org-worg-stats.php
http://orgmode.org/worg/org-mailing-list.php#sec-3

Thanks to Eric Schulte for write the babel file which
produced the commits stats (I'll update this graph from
time to time.)



This is so coool!

Reminders on the "biggest events" on this mailing list.
"POLL: the 40 variables project" ...

Wow!  Thanks Eric!


I saw this analysis of the R mailing lists a while ago,
it might be interesting to  do something similar with this list.

http://www.agrocampus-ouest.fr/math/useR-2009/slides/Bohn+Feinerer+Hornik+Theussl.pdf

___
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 ??? Cannot export custom link type to ASCII :-(

[Sebastian Rose]

Bastien  writes:
> Hi Sebastian,
>
> Sebastian Rose  writes:
>
>> Hmmm  this seems so deliberate...  For bbdb links this even seems to
>> make sense...  But how could I avoid this "footnote like" behaviour?
>
> Actually, I've wished for a long time that we can have a *real* footnote
> behavior for links when exporting to ASCII.
>
> For example:
>
>   This [[http://orgmode.org][Org]] thingy is great.
>
> Would be exported to:
>
>   This Org¹ thingy is great.
>
>   ¹ http://orgmode.org
>
> I'm putting this on my TODO list...




Yes.  But I want to avoid the footnote style for my custom "track:"
links.  Look at the track I ran today.

Who reads a footnote like this one (lines are not wrapped on export):


[2010-09-05--30.994--5:32]: track:((9.707050323377189 52.37053766338069)
(9.711363315473136 52.37529308313076)
(9.710655212293204 52.37074846474)
(9.71125602711254 52.3756658283)
(9.711813926587638 52.37641963648109)
(9.712114333997306 52.37687810926805)
(9.711763858795166 52.37705320097925)
(9.71047211417 52.377611655826854)
(9.709560871015128 52.37804391862884)
(9.707973003278312 52.37848927587801)
(9.706943035016593 52.37867265696918)
(9.705913066754874 52.37875124863228)
(9.705312251935538 52.37875124863228)
(9.704174995313224 52.378607163809775)
(9.70301628101879 52.37839758504682)
(9.701170921216544 52.37801772100373)
(9.699819087873038 52.37788673264495)
(9.697952270398673 52.37772954610157)
(9.696850776672363 52.377747447957255)
(9.695484638104972 52.37788673264495)
(9.694218635449943 52.378174906521316)
(9.693617820630607 52.378332091479415)
(9.692695140729484 52.37871195281822)
(9.691901206861075 52.379000121309296)
(9.691257476697501 52.379301386357405)
(9.68996286392212 52.38010518640359)
(9.690570831189689 52.38041473935315)
(9.689862728009757 52.38100415016248)
(9.689083099365234 52.38151976904499)
(9.688382148633536 52.38192099578275)
(9.687008857617911 52.38247109401651)
(9.685442447553214 52.3830604773757)
(9.684004783521232 52.383610561412425)
(9.68355417240673 52.383937989132725)
(9.68106508244091 52.384854773830995)
(9.68057155598217 52.384959548012894)
(9.680585861206055 52.385278671203096)
(9.680464267621574 52.38591560093584)
(9.680078029523429 52.38613824042515)
(9.676988124738273 52.3866620936179)
(9.675486087689933 52.38700259485967)
(9.67482089985424 52.38723832495006)
(9.673662185559806 52.38765739755821)
(9.673275947461661 52.38761810967017)
(9.668962955365714 52.38928126633751)
(9.667868614087638 52.389674128841754)
(9.667088985443115 52.38994083686471)
(9.66608762730175 52.39022413047344)
(9.664649963269767 52.39052531893909)
(9.66357707966381 52.39065626980484)
(9.660937785993156 52.390878885385035)
(9.659457206616935 52.39099674023763)
(9.65759038914257 52.39116697446916)
(9.655358791242179 52.39137649262204)
(9.651060104370117 52.391957463824156)
(9.651045799146232 52.391795525944076)
(9.650745391736564 52.391795525944076)
(9.65059518803173 52.39127173366993)
(9.650402068982658 52.39140268232121)
(9.645123481641349 52.391743146996376)
(9.644050598035392 52.39180862067127)
(9.642348289489746 52.391734853683936)
(9.640660285840568 52.39157291498709)
(9.638042449842033 52.39125863878343)
(9.636197090039786 52.39104912007113)
(9.635725021253165 52.39104912007113)
(9.6120285987854 52.388605098155104)
(9.60939645756298 52.38843005224972)
(9.606513977050781 52.38844794976713)
(9.60456132888794 52.388526524031036)
(9.602937698255118 52.38858720070138)
(9.593839645276603 52.38918959791672)
(9.590985774884757 52.38938603001387)
(9.58881855724 52.389608652000526)
(9.587101936231193 52.38985746348047)
(9.585750102887687 52.39009317832562)
(9.57517147053295 52.39243716300863)
(9.570751190076408 52.3934323367367)
(9.556417465100822 52.396627216511874)
(9.556117057691154 52.3949638125)
(9.554314613233146 52.39707238631737)
(9.55339192023 52.3970592931519)
(9.552597999463615 52.39719022463179)
(9.55148220051342 52.39750445859858)
(9.54998016346508 52.39802817690401)
(9.549422263989982 52.398132919819226)
(9.549765586743888 52.398800650059)
(9.550387859235343 52.399010131973554)
(9.54998016346508 52.398800650059)
(9.550001621137199 52.39876137208931)
(9.55244779575878 52.39851261080267)
(9.554328918457031 52.39846504052878)
(9.55596685398632

[Orgmode] Re: Using cdlatex-item within org-mode

[Jeff Horn]

Sorry, is this message lost in moderation?

Jeff

On Sat, Sep 4, 2010 at 3:33 PM, Jeff Horn  wrote:
> Should it be possible to use cdlatex-item in org-mode? (I read that
> org-cdlatex-mode has a subset of functionality in the org manual)
> Specifically, I am trying to use it from within an equation array.
>
> When I type `C-c -', a dash is inserted at the beginning of the array
> line. When I type `it', I receive an error stating `Symbol's
> function definition is void: reftex-what-environment'.
>
> Any ideas?
>
> Jeff
>
> --
> Jeffrey Horn
> PhD Student in Economics
> George Mason University
>
> (704) 271-4797
> jh...@gmu.edu
> jrhorn...@gmail.com
>



-- 
Jeffrey Horn
PhD Student in Economics
George Mason University

(704) 271-4797
jh...@gmu.edu
jrhorn...@gmail.com

___
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: Org file rendering/manipulation too slow

[Marcelo de Moraes Serpa]

Hi Nick,

The output of elp-results is attached. I have opened a big org file I
have, and navigated through the items a bit.

Thanks,

Marcelo.

On Mon, Aug 30, 2010 at 9:31 PM, Nick Dokos  wrote:
> Marcelo de Moraes Serpa  wrote:
>
>> Yeah, thanks. It is really a shame that emacs will run orgmode this
>> slow on OSX. OSX is now my platform of choice, and emacs my editor of
>> choice. I keep a big reference org file with tons of tons of notes,
>> but, even with the settings you suggested (thanks for that!) it is
>> still very slow. I'm considering switching my notes to evernote,
>> although I would really like to just stay with emacs+orgmode, but it's
>> just too slow as of now :(
>>
>
> Please take a profile: Just do
>
>       M-x elp-instrument-package  org 
>
> then run the slow command, then M-x elp-results and post the output to
> the list. It might not be enough to solve your problem but it would at
> least provide *some* information.
>
> Thanks,
> Nick
>
org-cycle 3   
0.050032  0.016677
org-cycle-internal-local  3   
0.04951   0.016503
org-optimize-window-after-visibility-change   2   
0.038067  0.0190335000
org-subtree-end-visible-p 1   
0.015067  0.015067
org-self-insert-command   12  
0.007179  0.00059825
org-fix-tags-on-the-fly   12  
0.003489  0.00029075
org-end-of-subtree7   
0.002255  0.0003221428
org-at-table-p16  
0.001906  0.0001191250
org-on-heading-p  12  
0.001669  0.0001390833
org-activate-footnote-links   26  
0.001309  5.034...e-05
org-activate-plain-links  34  
0.001188  3.497...e-05
org-align-tags-here   11  
0.001091  9.918...e-05
org-return1   
0.000976  0.000976
org-do-emphasis-faces 27  
0.000866  3.207...e-05
org-activate-tags 45  
0.000817  1.817...e-05
org-outline-level 82  
0.000611  7.463...e-06
org-unfontify-region  26  
0.000437  1.680...e-05
org-activate-dates38  
0.000411  1.084...e-05
org-activate-bracket-links32  
0.000409  1.281...e-05
org-cycle-show-empty-lines2   
0.000357  0.0001785
org-fontify-meta-lines-and-blocks 26  
0.000326  1.253...e-05
org-cycle-hide-archived-subtrees  2   
0.00032   0.00016
org-activate-angle-links  26  
0.000274  1.053...e-05
org-get-level-face228 
0.000252  1.109...e-06
org-show-entry1   
0.000214  0.000214
org-activate-code 26  
0.000173  6.653...e-06
org-back-to-heading   14  
0.000171  1.221...e-05
org-cycle-hide-drawers3   
0.000152  5.066...e-05
org-get-todo-face 19  
0.00015   7.894...e-06
org-font-lock-add-priority-faces  26  
0.000138  5.307...e-06
org-remove-flyspell-overlays-in   46  
0.000120  2.630...e-06
org-hide-block-toggle-maybe   3   
0.000101  3.399...e-05
org-hide-wide-columns 26  
9.300...e-05  3.576...e-06
org-remove-font-lock-display-properties   26  
7.800...e-05  3.000...e-06
org-at-item-p 3   
4.1e-05   1.366...e-05
org-babel-hide-result-toggle-maybe3   
3.9e-05   1.3e-05
org-at-heading-p  4   
3.8e-05   9.5e-06
org-hide-archived-subtrees1   
3.2e-05   3.2e-05
org-do-latex-and-special-faces26  
3.100...e-05  1.192...e-06
org-font-lock-hook26  
3.100...e

[Orgmode] [PATCH] Allow no stripping of blank lines from code

[Dan Davison]

Now that we can issue TAB in a code block and have it act according to
language [see org-src-tab-acts-natively], the following is a minor
frustration: if you try to insert a blank line at the beginning/end of
the block (perhaps to introduce a new first/last line), then on TAB it
disappears because org-edit-src-exit strips leading and trailing blank
lines. This patch introduces a variable that turns off that behaviour.

The default is still to strip lines. I am slightly wondering what the
reason for that default was. I can see it could be useful for
artist-mode, but for genuine code blocks should the default be to give
the user responsibility for curating leading/trailing blank lines?

Dan

--8<---cut here---start->8---
commit 84503c83d143b40bded8122e45ffba703c4035a1
Author: Dan Davison 
Date:   Sun Sep 5 18:55:06 2010 -0400

Optionally prevent stripping of blank lines from code blocks

* org-src.el (org-edit-src-exit): Only strip leading and
trailing blank lines if
`org-src-strip-leading-and-trailing-blank-lines' is non-nil
(org-src-strip-leading-and-trailing-blank-lines): New variable

diff --git a/lisp/org-src.el b/lisp/org-src.el
index f11eec2..d877925 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -109,6 +109,12 @@ editing it with \\[org-edit-src-code].  Has no effect if
   :group 'org-edit-structure
   :type 'integer)
 
+(defcustom org-src-strip-leading-and-trailing-blank-lines t
+  "If non-nil, blank lines are removed when exiting the code edit
+buffer."
+  :group 'org-edit-structure
+  :type 'boolean)
+
 (defcustom org-edit-src-persistent-message t
   "Non-nil means show persistent exit help message while editing src examples.
 The message is shown in the header-line, which will be created in the
@@ -577,11 +583,12 @@ the language, a switch telling if the content should be 
in a single line."
 (delta 0) code line col indent)
 (when allow-write-back-p
   (unless preserve-indentation (untabify (point-min) (point-max)))
-  (save-excursion
-   (goto-char (point-min))
-   (if (looking-at "[ \t\n]*\n") (replace-match ""))
-   (unless macro
- (if (re-search-forward "\n[ \t\n]*\\'" nil t) (replace-match "")
+  (if org-src-strip-leading-and-trailing-blank-lines
+ (save-excursion
+   (goto-char (point-min))
+   (if (looking-at "[ \t\n]*\n") (replace-match ""))
+   (unless macro
+ (if (re-search-forward "\n[ \t\n]*\\'" nil t) (replace-match 
""))
 (setq line (if (org-bound-and-true-p org-edit-src-force-single-line)
   1
 (org-current-line))
--8<---cut here---end--->8---


___
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: Org file rendering/manipulation too slow

[Nick Dokos]

Marcelo de Moraes Serpa  wrote:

> Hi Nick,
> 
> The output of elp-results is attached. I have opened a big org file I
> have, and navigated through the items a bit.
> 
> Thanks,
> 
> Marcelo.
> 
> On Mon, Aug 30, 2010 at 9:31 PM, Nick Dokos  wrote:
> > Marcelo de Moraes Serpa  wrote:
> >
> >> Yeah, thanks. It is really a shame that emacs will run orgmode this
> >> slow on OSX. OSX is now my platform of choice, and emacs my editor of
> >> choice. I keep a big reference org file with tons of tons of notes,
> >> but, even with the settings you suggested (thanks for that!) it is
> >> still very slow. I'm considering switching my notes to evernote,
> >> although I would really like to just stay with emacs+orgmode, but it's
> >> just too slow as of now :(
> >>
> >
> > Please take a profile: Just do
> >
> >       M-x elp-instrument-package  org 
> >
> > then run the slow command, then M-x elp-results and post the output to
> > the list. It might not be enough to solve your problem but it would at
> > least provide *some* information.
> >
> > Thanks,
> > Nick
> >

OK - thanks for doing that. Given the stats:

,
| org-cycle 3   
0.050032  0.016677
| org-cycle-internal-local  3   
0.04951   0.016503
| org-optimize-window-after-visibility-change   2   
0.038067  0.0190335000
| ...
`

it seems clear that org-mode is not the culprit and, at 0.05s, any
improvements made there are going to be completely swamped by the real
time sink (maybe the display code if I understand things correctly.)
Also, presumably you are not complaining about the 50ms delay: that
would be almost unnoticeable. How long does it take for emacs to show
you the file?

Some questions:

How much memory do you have on your system? How much memory does emacs
consume? Is your disk active when emacs is taking forever?

On linux, I get the first with

 sed 1q /proc/meminfo

and the second with

 ps awlx | grep emacs

and look at the RSS field (field 8 in the output); e.g.

,
| $ ps awlx | grep emacs
| 0  9772 11777 1  20   0  51284 32660 -  R?  1:02 
/usr/local/bin/emacs
`

shows me that emacs is consuming roughly 32Mb. I have 1Gb of memory on
the machine, so that's a comfortable fit (about 1/30 of available
memory: leaves just enough space for X and firefox :-) ). If your
numbers are closer, then maybe that's a problem: in particular, if your
disk goes wild while emacs is trying to do its thing, you are probably
swapping heavily and your performance will *really* be in the
toilet. The only solution is to buy more memory (assuming your machine
can handle it.)

I should say that I know very little about Darwin, so all of the above
is pure speculation. Parts of it may be applicable: you'd need to check
with an OSX expert for more details.

If there are no problems of the sort described above, I would ask in an
emacs forum about the performance of the display engine on Darwin: do
other people see the slowness? It would show up even without org
(although org make the situation marginally worse to be sure.)  Given
the font-lock setting that Bernt dug up, it seems likely that if memory
is not the problem, the display engine is.

HTH,
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: [Orgmode] Re: Org file rendering/manipulation too slow

[Marcelo de Moraes Serpa]

HI Nicholas, thanks for the reply,

>How long does it take for emacs to show
>you the file?

>From the moment I press  on the minibuffer to the moment the
whole file is rendered, it takes about 3 seconds. So, it does take
longer than I would expect.

I have a 10-months old Macbook, and its specs are quite recent, check
out (from System Profiler):

  Model Name:   MacBook
  Model Identifier: MacBook6,1
  Processor Name:   Intel Core 2 Duo
  Processor Speed:  2.26 GHz
  Number Of Processors: 1
  Total Number Of Cores:2
  L2 Cache: 3 MB
  Memory:   4 GB
  Bus Speed:1.07 GHz
  Boot ROM Version: MB61.00C8.B00
  SMC Version (system): 1.51f53
  Serial Number (system):   W89483Q78PX
  Hardware UUID:413C6EF2-12B3-5C38-A3CA-5A1F924867D7
  Sudden Motion Sensor:
  State:Enabled

So, the system is quite capable and is definetly should not be the bottleneck.

What I note though is that when I open this big org file and try to
naviagate around, the Emacs.app CPU usage goes up to 100% and then
gradually goes down to 0 as I stop giving any other commands. Check
out the screenshot below:

http://i56.tinypic.com/123sbcj.png

When I run "ps awlx | grep emacs", I get the following output:

 >501  5733  5578   0  31  0  2425520168 -  R+   s000
0:00.00 grep emacs

Some additional information:

Emacs version string:

>GNU Emacs 23.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.29) of 2010-05-08 
>on black.local

Org-mode version string:

>Org-mode version 7.01trans (release_7.01g.20.gdd484.dirty)

It is really unfortunate that org-mode runs like this on OSX. I can't
really think of anything else I could use to manage my personal
information and todo lists, but handling big orgfiles, as of now, is
really starting to be a blocker :-(

Thanks for the help,

Marcelo.


On Sun, Sep 5, 2010 at 9:07 PM, Nick Dokos  wrote:
> Marcelo de Moraes Serpa  wrote:
>
>> Hi Nick,
>>
>> The output of elp-results is attached. I have opened a big org file I
>> have, and navigated through the items a bit.
>>
>> Thanks,
>>
>> Marcelo.
>>
>> On Mon, Aug 30, 2010 at 9:31 PM, Nick Dokos  wrote:
>> > Marcelo de Moraes Serpa  wrote:
>> >
>> >> Yeah, thanks. It is really a shame that emacs will run orgmode this
>> >> slow on OSX. OSX is now my platform of choice, and emacs my editor of
>> >> choice. I keep a big reference org file with tons of tons of notes,
>> >> but, even with the settings you suggested (thanks for that!) it is
>> >> still very slow. I'm considering switching my notes to evernote,
>> >> although I would really like to just stay with emacs+orgmode, but it's
>> >> just too slow as of now :(
>> >>
>> >
>> > Please take a profile: Just do
>> >
>> >       M-x elp-instrument-package  org 
>> >
>> > then run the slow command, then M-x elp-results and post the output to
>> > the list. It might not be enough to solve your problem but it would at
>> > least provide *some* information.
>> >
>> > Thanks,
>> > Nick
>> >
>
> OK - thanks for doing that. Given the stats:
>
> ,
> | org-cycle                                                     3           
> 0.050032      0.016677
> | org-cycle-internal-local                                      3           
> 0.04951       0.016503
> | org-optimize-window-after-visibility-change                   2           
> 0.038067  0.0190335000
> | ...
> `
>
> it seems clear that org-mode is not the culprit and, at 0.05s, any
> improvements made there are going to be completely swamped by the real
> time sink (maybe the display code if I understand things correctly.)
> Also, presumably you are not complaining about the 50ms delay: that
> would be almost unnoticeable. How long does it take for emacs to show
> you the file?
>
> Some questions:
>
> How much memory do you have on your system? How much memory does emacs
> consume? Is your disk active when emacs is taking forever?
>
> On linux, I get the first with
>
>         sed 1q /proc/meminfo
>
> and the second with
>
>         ps awlx | grep emacs
>
> and look at the RSS field (field 8 in the output); e.g.
>
> ,
> | $ ps awlx | grep emacs
> | 0  9772 11777     1  20   0  51284 32660 -      R    ?          1:02 
> /usr/local/bin/emacs
> `
>
> shows me that emacs is consuming roughly 32Mb. I have 1Gb of memory on
> the machine, so that's a comfortable fit (about 1/30 of available
> memory: leaves just enough space for X and firefox :-) ). If your
> numbers are closer, then maybe that's a problem: in particular, if your
> disk goes wild while emacs is trying to do its thing, you are probably
> swapping heavily and your performance will *really* be in the
> toilet. The only solution is to buy more memory (assuming your machine
> can handle it.)
>
> I should say that I know very little about Darwin, so all of the above
> is pure speculation. Parts of it may be applicable: you'd need to check
> with an OSX expert for more details.
>
> If there are no problems of the sort described a

Re: [Orgmode] Re: Org file rendering/manipulation too slow

[Nick Dokos]

Marcelo de Moraes Serpa  wrote:

> HI Nicholas, thanks for the reply,
> 
> >How long does it take for emacs to show
> >you the file?
> 
> From the moment I press  on the minibuffer to the moment the
> whole file is rendered, it takes about 3 seconds. So, it does take
> longer than I would expect.
> 
> I have a 10-months old Macbook, and its specs are quite recent, check
> out (from System Profiler):
> 
>   Model Name: MacBook
>   Model Identifier:   MacBook6,1
>   Processor Name: Intel Core 2 Duo
>   Processor Speed:2.26 GHz
>   Number Of Processors:   1
>   Total Number Of Cores:  2
>   L2 Cache:   3 MB
>   Memory: 4 GB
>   Bus Speed:  1.07 GHz
>   Boot ROM Version:   MB61.00C8.B00
>   SMC Version (system):   1.51f53
>   Serial Number (system): W89483Q78PX
>   Hardware UUID:  413C6EF2-12B3-5C38-A3CA-5A1F924867D7
>   Sudden Motion Sensor:
>   State:  Enabled
> 
> So, the system is quite capable and is definetly should not be the bottleneck.
> 

It depends of course on what *else* you are running, but prima facie,
swapping doesn't look to be the problem. Nevertheless, is a disk going
wild while you are opening the file?

> What I note though is that when I open this big org file and try to
> naviagate around, the Emacs.app CPU usage goes up to 100% and then
> gradually goes down to 0 as I stop giving any other commands. Check
> out the screenshot below:
> 
> http://i56.tinypic.com/123sbcj.png
> 

Does this happen when you open *any* large file or only when you open
the org file (and iirc, it was not a very big file: smaller than 1Mb?)

> When I run "ps awlx | grep emacs", I get the following output:
> 
>  >501  5733  5578   0  31  0  2425520168 -  R+   s000
> 0:00.00 grep emacs
> 

This is the wrong process: this is the line for the "grep emacs"
command, not for emacs itself. Maybe try "grep Emacs"? I don't know
what the emacs command name is on OSX.

> ...
> It is really unfortunate that org-mode runs like this on OSX. I can't
> really think of anything else I could use to manage my personal
> information and todo lists, but handling big orgfiles, as of now, is
> really starting to be a blocker :-(
> 

But is it org mode that runs like this? or something else? The elp stats
showed that org-mode was pretty much in the noise.

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: [Orgmode] Re: Org file rendering/manipulation too slow

[Marcelo de Moraes Serpa]

>It depends of course on what *else* you are running, but prima facie,
>swapping doesn't look to be the problem. Nevertheless, is a disk going
>wild while you are opening the file?

No. CPU is going wild, though.

>This is the wrong process: this is the line for the "grep emacs"
>command, not for emacs itself. Maybe try "grep Emacs"? I don't know
>what the emacs command name is on OSX.

Sorry about that. Here it is:

>501  6163   213   0  48  0  2858968  46920 -  S  ??0:04.30 
>/Applications/Emacs.app/Contents/MacOS/Emacs -psn_0_782527

>But is it org mode that runs like this? or something else? The elp stats
>showed that org-mode was pretty much in the noise.

>Does this happen when you open *any* large file or only when you open
>the org file (and iirc, it was not a very big file: smaller than 1Mb?)

Seems so. For example, if I open the same org file without orgmode
activated, it renders pretty fast, without any apparent issues. I also
have some big ruby script files which don't have any rendering
performance issues whatsoever.

I might have to reinstall emacs and configure things from scratch to
try to isolate the issue.

Thanks!

Marcelo.





On Sun, Sep 5, 2010 at 11:08 PM, Nick Dokos  wrote:
> Marcelo de Moraes Serpa  wrote:
>
>> HI Nicholas, thanks for the reply,
>>
>> >How long does it take for emacs to show
>> >you the file?
>>
>> From the moment I press  on the minibuffer to the moment the
>> whole file is rendered, it takes about 3 seconds. So, it does take
>> longer than I would expect.
>>
>> I have a 10-months old Macbook, and its specs are quite recent, check
>> out (from System Profiler):
>>
>>   Model Name: MacBook
>>   Model Identifier:   MacBook6,1
>>   Processor Name:     Intel Core 2 Duo
>>   Processor Speed:    2.26 GHz
>>   Number Of Processors:       1
>>   Total Number Of Cores:      2
>>   L2 Cache:   3 MB
>>   Memory:     4 GB
>>   Bus Speed:  1.07 GHz
>>   Boot ROM Version:   MB61.00C8.B00
>>   SMC Version (system):       1.51f53
>>   Serial Number (system):     W89483Q78PX
>>   Hardware UUID:      413C6EF2-12B3-5C38-A3CA-5A1F924867D7
>>   Sudden Motion Sensor:
>>   State:      Enabled
>>
>> So, the system is quite capable and is definetly should not be the 
>> bottleneck.
>>
>
> It depends of course on what *else* you are running, but prima facie,
> swapping doesn't look to be the problem. Nevertheless, is a disk going
> wild while you are opening the file?
>
>> What I note though is that when I open this big org file and try to
>> naviagate around, the Emacs.app CPU usage goes up to 100% and then
>> gradually goes down to 0 as I stop giving any other commands. Check
>> out the screenshot below:
>>
>> http://i56.tinypic.com/123sbcj.png
>>
>
> Does this happen when you open *any* large file or only when you open
> the org file (and iirc, it was not a very big file: smaller than 1Mb?)
>
>> When I run "ps awlx | grep emacs", I get the following output:
>>
>>  >501  5733  5578   0  31  0  2425520    168 -      R+   s000
>> 0:00.00 grep emacs
>>
>
> This is the wrong process: this is the line for the "grep emacs"
> command, not for emacs itself. Maybe try "grep Emacs"? I don't know
> what the emacs command name is on OSX.
>
>> ...
>> It is really unfortunate that org-mode runs like this on OSX. I can't
>> really think of anything else I could use to manage my personal
>> information and todo lists, but handling big orgfiles, as of now, is
>> really starting to be a blocker :-(
>>
>
> But is it org mode that runs like this? or something else? The elp stats
> showed that org-mode was pretty much in the noise.
>
> 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: [Orgmode] Re: Org file rendering/manipulation too slow

[Marcelo de Moraes Serpa]

So, I just found out something interesting. I told emacs not to load
my init.el file (i.e vanilla emacs). I then opened the same "big"
orgmode file and it rendered pretty quickly! Also, navigating through
the file and sending other org commands happens instantly. It is
probably some configuration that I have throughout my big suite of el
files. I will try to isolate it tomorrow and share the veredict with
you guys.

Marcelo.

On Sun, Sep 5, 2010 at 11:19 PM, Marcelo de Moraes Serpa
 wrote:
>>It depends of course on what *else* you are running, but prima facie,
>>swapping doesn't look to be the problem. Nevertheless, is a disk going
>>wild while you are opening the file?
>
> No. CPU is going wild, though.
>
>>This is the wrong process: this is the line for the "grep emacs"
>>command, not for emacs itself. Maybe try "grep Emacs"? I don't know
>>what the emacs command name is on OSX.
>
> Sorry about that. Here it is:
>
>>501  6163   213   0  48  0  2858968  46920 -      S      ??    0:04.30 
>>/Applications/Emacs.app/Contents/MacOS/Emacs -psn_0_782527
>
>>But is it org mode that runs like this? or something else? The elp stats
>>showed that org-mode was pretty much in the noise.
>
>>Does this happen when you open *any* large file or only when you open
>>the org file (and iirc, it was not a very big file: smaller than 1Mb?)
>
> Seems so. For example, if I open the same org file without orgmode
> activated, it renders pretty fast, without any apparent issues. I also
> have some big ruby script files which don't have any rendering
> performance issues whatsoever.
>
> I might have to reinstall emacs and configure things from scratch to
> try to isolate the issue.
>
> Thanks!
>
> Marcelo.
>
>
>
>
>
> On Sun, Sep 5, 2010 at 11:08 PM, Nick Dokos  wrote:
>> Marcelo de Moraes Serpa  wrote:
>>
>>> HI Nicholas, thanks for the reply,
>>>
>>> >How long does it take for emacs to show
>>> >you the file?
>>>
>>> From the moment I press  on the minibuffer to the moment the
>>> whole file is rendered, it takes about 3 seconds. So, it does take
>>> longer than I would expect.
>>>
>>> I have a 10-months old Macbook, and its specs are quite recent, check
>>> out (from System Profiler):
>>>
>>>   Model Name: MacBook
>>>   Model Identifier:   MacBook6,1
>>>   Processor Name:     Intel Core 2 Duo
>>>   Processor Speed:    2.26 GHz
>>>   Number Of Processors:       1
>>>   Total Number Of Cores:      2
>>>   L2 Cache:   3 MB
>>>   Memory:     4 GB
>>>   Bus Speed:  1.07 GHz
>>>   Boot ROM Version:   MB61.00C8.B00
>>>   SMC Version (system):       1.51f53
>>>   Serial Number (system):     W89483Q78PX
>>>   Hardware UUID:      413C6EF2-12B3-5C38-A3CA-5A1F924867D7
>>>   Sudden Motion Sensor:
>>>   State:      Enabled
>>>
>>> So, the system is quite capable and is definetly should not be the 
>>> bottleneck.
>>>
>>
>> It depends of course on what *else* you are running, but prima facie,
>> swapping doesn't look to be the problem. Nevertheless, is a disk going
>> wild while you are opening the file?
>>
>>> What I note though is that when I open this big org file and try to
>>> naviagate around, the Emacs.app CPU usage goes up to 100% and then
>>> gradually goes down to 0 as I stop giving any other commands. Check
>>> out the screenshot below:
>>>
>>> http://i56.tinypic.com/123sbcj.png
>>>
>>
>> Does this happen when you open *any* large file or only when you open
>> the org file (and iirc, it was not a very big file: smaller than 1Mb?)
>>
>>> When I run "ps awlx | grep emacs", I get the following output:
>>>
>>>  >501  5733  5578   0  31  0  2425520    168 -      R+   s000
>>> 0:00.00 grep emacs
>>>
>>
>> This is the wrong process: this is the line for the "grep emacs"
>> command, not for emacs itself. Maybe try "grep Emacs"? I don't know
>> what the emacs command name is on OSX.
>>
>>> ...
>>> It is really unfortunate that org-mode runs like this on OSX. I can't
>>> really think of anything else I could use to manage my personal
>>> information and todo lists, but handling big orgfiles, as of now, is
>>> really starting to be a blocker :-(
>>>
>>
>> But is it org mode that runs like this? or something else? The elp stats
>> showed that org-mode was pretty much in the noise.
>>
>> 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: [Orgmode] BUG ??? Cannot export custom link type to ASCII :-(

[Carsten Dominik]

Hi Sebastian,

I have just pushed the code that was needed to allow custom link
formatting for ASCII export, like you have implemented it.  This was
simple an omission in the ascii exporter.
So I hope it will work now

- Carsten

On Mon, Sep 6, 2010 at 1:01 AM, Sebastian Rose  wrote:
> Bastien  writes:
>> Hi Sebastian,
>>
>> Sebastian Rose  writes:
>>
>>> Hmmm  this seems so deliberate...  For bbdb links this even seems to
>>> make sense...  But how could I avoid this "footnote like" behaviour?
>>
>> Actually, I've wished for a long time that we can have a *real* footnote
>> behavior for links when exporting to ASCII.
>>
>> For example:
>>
>>   This [[http://orgmode.org][Org]] thingy is great.
>>
>> Would be exported to:
>>
>>   This Org¹ thingy is great.
>>
>>   ¹ http://orgmode.org
>>
>> I'm putting this on my TODO list...
>
>
>
>
> Yes.  But I want to avoid the footnote style for my custom "track:"
> links.  Look at the track I ran today.
>
> Who reads a footnote like this one (lines are not wrapped on export):
>
>
> [2010-09-05--30.994--5:32]: track:((9.707050323377189 52.37053766338069)
>        (9.711363315473136 52.37529308313076)
>        (9.710655212293204 52.37074846474)
>        (9.71125602711254 52.3756658283)
>        (9.711813926587638 52.37641963648109)
>        (9.712114333997306 52.37687810926805)
>        (9.711763858795166 52.37705320097925)
>        (9.71047211417 52.377611655826854)
>        (9.709560871015128 52.37804391862884)
>        (9.707973003278312 52.37848927587801)
>        (9.706943035016593 52.37867265696918)
>        (9.705913066754874 52.37875124863228)
>        (9.705312251935538 52.37875124863228)
>        (9.704174995313224 52.378607163809775)
>        (9.70301628101879 52.37839758504682)
>        (9.701170921216544 52.37801772100373)
>        (9.699819087873038 52.37788673264495)
>        (9.697952270398673 52.37772954610157)
>        (9.696850776672363 52.377747447957255)
>        (9.695484638104972 52.37788673264495)
>        (9.694218635449943 52.378174906521316)
>        (9.693617820630607 52.378332091479415)
>        (9.692695140729484 52.37871195281822)
>        (9.691901206861075 52.379000121309296)
>        (9.691257476697501 52.379301386357405)
>        (9.68996286392212 52.38010518640359)
>        (9.690570831189689 52.38041473935315)
>        (9.689862728009757 52.38100415016248)
>        (9.689083099365234 52.38151976904499)
>        (9.688382148633536 52.38192099578275)
>        (9.687008857617911 52.38247109401651)
>        (9.685442447553214 52.3830604773757)
>        (9.684004783521232 52.383610561412425)
>        (9.68355417240673 52.383937989132725)
>        (9.68106508244091 52.384854773830995)
>        (9.68057155598217 52.384959548012894)
>        (9.680585861206055 52.385278671203096)
>        (9.680464267621574 52.38591560093584)
>        (9.680078029523429 52.38613824042515)
>        (9.676988124738273 52.3866620936179)
>        (9.675486087689933 52.38700259485967)
>        (9.67482089985424 52.38723832495006)
>        (9.673662185559806 52.38765739755821)
>        (9.673275947461661 52.38761810967017)
>        (9.668962955365714 52.38928126633751)
>        (9.667868614087638 52.389674128841754)
>        (9.667088985443115 52.38994083686471)
>        (9.66608762730175 52.39022413047344)
>        (9.664649963269767 52.39052531893909)
>        (9.66357707966381 52.39065626980484)
>        (9.660937785993156 52.390878885385035)
>        (9.659457206616935 52.39099674023763)
>        (9.65759038914257 52.39116697446916)
>        (9.655358791242179 52.39137649262204)
>        (9.651060104370117 52.391957463824156)
>        (9.651045799146232 52.391795525944076)
>        (9.650745391736564 52.391795525944076)
>        (9.65059518803173 52.39127173366993)
>        (9.650402068982658 52.39140268232121)
>        (9.645123481641349 52.391743146996376)
>        (9.644050598035392 52.39180862067127)
>        (9.642348289489746 52.391734853683936)
>        (9.640660285840568 52.39157291498709)
>        (9.638042449842033 52.39125863878343)
>        (9.636197090039786 52.39104912007113)
>        (9.635725021253165 52.39104912007113)
>        (9.6120285987854 52.388605098155104)
>        (9.60939645756298 52.38843005224972)
>        (9.606513977050781 52.38844794976713)
>        (9.60456132888794 52.388526524031036)
>        (9.602937698255118 52.38858720070138)
>        (9.593839645276603 52.38918959791672)
>        (9.590985774884757 52.38938603001387)
>        (9.58881855724 52.389608652000526)
>        (9.587101936231193 52.38985746348047)
>        (9.585750102887687 52.39009317832562)
>        (9.57517147053295 52.39243716300863)
>        (9.570751190076408 52.3934323367367)
>        (9.556417465100822 52.396627216511874)
>        (9.556117057691154 52.3949638125)
>        (9.554314613233146 52.39707238631737)
>        (9.55339192023 52.3970592931519)
>        (9.552597999463615 52.39719022463179)
>        (9.551482200513

Re: [Orgmode] A few stats and figures about org/worg and the mailing list

[Carsten Dominik]

On Mon, Sep 6, 2010 at 12:59 AM, Erik Iverson  wrote:
> On 09/05/2010 05:52 PM, Sebastian Rose wrote:
>>
>> Bastien  writes:
>>>
>>> http://orgmode.org/worg/org-worg-stats.php
>>> http://orgmode.org/worg/org-mailing-list.php#sec-3
>>>
>>> Thanks to Eric Schulte for write the babel file which
>>> produced the commits stats (I'll update this graph from
>>> time to time.)
>>
>>
>> This is so coool!
>>
>> Reminders on the "biggest events" on this mailing list.
>> "POLL: the 40 variables project" ...

Of cause, we could repeat and do a much better job.  We have now
code in the bug reporter that automatically writes the entire local
customization into a buffer, in a way that can be read back into a
lisp variable.  So the analysis could be totally automated... :-)

- 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

Re: [Orgmode] BUG ??? Cannot export custom link type to ASCII :-(

[Bastien]

Sebastian Rose  writes:

> Yes.  But I want to avoid the footnote style for my custom "track:"
> links.  Look at the track I ran today.

(Er.. that's a crazy link!)


Actually it would make sense to handle how custom type links are
exported in the custom type file itself.

For example org-bbdb.el would have a function `org-bbdb-export-link'
taking care of the various way BBDB links have to be represented in
HTML, LaTeX, etc.

-- 
 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