Re: [O] Show TODO item in table of contents

[Nicolas Goaziou]

Hello,

Rainer Stengele  writes:

> I just tried out. The TOC includes the todo items.
> I just can't remember if before the todo items were also colored in the TOC.
> Could it be that the patch removed that colorizing?

I cannot reproduce it, i.e. TODO are still colored.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Rüdiger Sonderfeld  writes:

> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
>> Anyway, I don't think this is a good idea to introduce a new syntax just
>> to avoid a one-liner (or a hook, see below). Also, this would only make
>> sense in few export back-ends.
>
> But is it really a new syntax or just support for an existing Emacs 
> convention?  See (info "(emacs) Pages").
>
> It seems like a feature which could be supported in many back-ends: LaTeX, 
> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.

I do not question this.

My point is that introducing this new syntax would bring up nothing that
can already be achieved using filters or hooks.

So, is this feature a must-have? Or would a filter template in Worg more
appropriate in this case?


Regards,

-- 
Nicolas Goaziou

Re: [O] ox-bibtex.el -- how to join sequential citations

[Nicolas Goaziou]

Hello,

Feng Shu  writes:

> Eric Schulte  writes:
>
>> When exporting multiple sequential citations e.g., cite:foo cite:bar
>> etc... I would like to see something like the following (latex used for
>> this example) "\cite{foo, bar}", but instead I'm getting "\cite{foo}
>> \cite{bar}", which leads to poorly formed PDFs (a similar thing happens
>> for HTML export).
>
> May be you should use \cite{foo, bar} directly in org file.

That was, indeed, the original way to handle citations in the former
org-export-bibtex.el. It is still supported in both LaTeX, obviously,
and HTML (which will split the above among two anchors).

"cite" link support was added later, and is lacking in this area.

>> My question is how best to fix this, should I write a filter function,
>> or does the export engine already have processes in place to handle
>> these sorts of export context issues?

At the user level, a filter is definitely the way to go.

Though, it is an interesting feature to implement in ox-bibtex.el. One
idea would be to write another parse-tree filter function which would
change cite links into \cite{...} commands and consecutive cite links
into \cite{..., ...} commands.

This would also allow us to get rid of both `org-html-link' and
`org-latex-link' advices, as no more cite link would be left in the
parse tree anyway.

What do you think?


Regards,

-- 
Nicolas Goaziou

[O] Koma-letter bug: backaddress option not included in latex export

[James Harkins]

I believe I've found a bug in ox-koma-letter.el. Org-mode version 8.2 
(release_8.2-2-g18c7c4 @ /home/dlm/share/org-mode.git/lisp/)


Accepted values for the "backaddress" option are "t" or "nil."

If the option is "t," then the export contains a line 
"\KOMAoption{backaddress}{true}."


If the option is nil, I would expect a line 
"\KOMAoption{backaddress}{false}" but *the line is omitted*. So, LaTeX 
prints the back address anyway, even though the option is explicitly set to 
disable the back address.


I think the problem is here:

  (let ((with-backaddress (plist-get info :with-backaddress))
	 (with-backaddress-set (plist-get info 
:with-backaddress-changed-in-buffer-p))

..
 (when with-backaddress-set
	(format "\\KOMAoption{backaddress}{%s}\n" (if with-backaddress "true" 
"false")))


Somehow, when backaddress is nil, with-backaddress-set must be false, 
causing the line not to be generated.


**Update**: Same problem with #+OPTIONS: foldmarks. Possibly all the 
options are broken.


ECM (the simple example at [1], with one #+OPTIONS line added):

[1] http://orgmode.org/worg/exporters/koma-letter-export.html

#+LATEX_CLASS: my-letter
#+TITLE: A simple letter
#+DATE: April 22, 2013
#+AUTHOR: Jane Doe
#+OPTIONS: backaddress:nil
#+FROM_ADDRESS: Some Street 1\\
#+FROM_ADDRESS: 12345 Some City
#+TO_ADDRESS: John Doe\\
#+TO_ADDRESS: Other Street 1\\
#+TO_ADDRESS: 54321 Other City
#+OPENING: Dear John,
#+CLOSING: Yours truly,
#+SIGNATURE: Jane
#+LANGUAGE: en

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.

-->

% Created 2013-11-24 Sun 17:27
\documentclass{scrlttr2}
\usepackage[english]{babel}
\setkomavar{fromemail}{dlm@dlm-A6200}
\LoadLetterOption{NF}
\setkomavar{fromname}{Jane Doe}
\setkomavar{fromaddress}{Some Street 1
12345 Some City}
\setkomavar{signature}{Jane}
\date{April 22, 2013}
\begin{document}

\setkomavar{subject}{A simple letter}

\begin{letter}{%
John Doe
Other Street 1
54321 Other City}

\opening{Dear John,}

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.

\closing{Yours truly,}

\end{letter}

\end{document}

~~~

Change it to backaddress:t and you'll see the difference.

hjh

Re: [O] Koma-letter bug: backaddress option not included in latex export

[Rasmus]

James,

Thanks for the bug report.  I'll fix it.

–Rasmus

-- 
This space is left intentionally blank

[O] More koma confusion: subject option

[James Harkins]

According to [1], "#+OPTIONS: subject:nil" should suppress printing the 
#+TITLE at the top of the letter. It seems that the previous bug prevents 
the expected line "\KOMAoption{subject}{untitled}" from being generated.


Okay... so, what if I set "#+OPTIONS: subject:untitled"? Then I get 
something like:


\KOMAoption{subject}{untitled}
\setkomavar{subject}{The title}

.. and LaTeX prints "The title" in bold, above the salutation.

If I remove the #+TITLE line (or comment it out), then the exporter assumes 
that the title should be the file name, minus the .org extension. This 
conflicts with [1], which claims that the default subject is an empty 
string.


I can suppress the subject by providing an empty #+TITLE line, but the 
documentation suggests that this should not be necessary.


??

hjh

[1] http://orgmode.org/worg/exporters/koma-letter-export.html

Re: [O] [PATCH] Re: \newpage in HTML export

[Eric Abrahamsen]

On 11/24/13 16:31 PM, Nicolas Goaziou wrote:
> Hello,
>
> Rüdiger Sonderfeld  writes:
>
>> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
>>> Anyway, I don't think this is a good idea to introduce a new syntax just
>>> to avoid a one-liner (or a hook, see below). Also, this would only make
>>> sense in few export back-ends.
>>
>> But is it really a new syntax or just support for an existing Emacs 
>> convention?  See (info "(emacs) Pages").
>>
>> It seems like a feature which could be supported in many back-ends: LaTeX, 
>> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.
>
> I do not question this.
>
> My point is that introducing this new syntax would bring up nothing that
> can already be achieved using filters or hooks.
>
> So, is this feature a must-have? Or would a filter template in Worg more
> appropriate in this case?

It's not that everyone is desperate to have this in org proper. Putting
it into the code base vs making a hook: my guess is the number of LOC
would be very nearly exactly the same, and there's literally no
practical difference in the result. When "why" and "why not" are
perfectly balanced, it may be better to do nothing.

But I think it just *feels* right, because the page delimiter already
seems like a first-class citizen in emacs. I'll admit it's also
partially because it's a control character. Control character! Must be
serious programming. I also like the thought of a new org user sticking
one in their document, exporting, and finding that org does the right
thing.

At this point, I'm pretty much neutral buoyancy on the issue, though...

Eric

[O] Implementing Org-mode tools in languages other than ELISP (was: Converting org-mode/org-contacts to VCard (importing to Android))

[Karl Voit]

Executive summary of this rather long email: I am aware that ELISP
is the language of choice for Org-mode features/tools. Here, I
describe my motivation behind using Python instead.


* Rüdiger Sonderfeld  wrote:
> On Friday 22 November 2013 18:09:42 Karl Voit wrote:
>
> Org-contacts has an :ICON: property and supports Gravatar.  It doesn't seem 
> to 
> be handled in the VCard export though.

:ICON:, I see. Thanks.

>> You see: I want to have ways to tweak the export process. And as
>> long as I don't know ELISP that well, I stick to the tools I know.
>
> I understand that and it solved your problem for now.  

Exactly.

> But having an external tool in a different programming language is
> usually not a good idea to solve the problem in the long run.  The
> code base of org-contacts and your tool is under the risk of
> diverting quickly.  If it's in org-contacts then it is maintained
> in one piece and easily accessible to other users.

Don't worry: I totally agree. :-)

> So my point is you should take a look at elisp.  It's a lot of fun
> to use and if you are using org-mode and Emacs then you will have
> to learn it sooner or later.

I tried but I could not get a decent progress to implement the
features I want to use. It is a rather high learning effort. I am
not only referring to ELISP as a language. The basics are not that
hard to learn. However, the more important part is to get into the
existing libraries and their feature-set. For me, I could not get
into it or I am not patient any more :-) It might be laziness or my
brain might not be compatible with the world of functional
programming languages.

Therefore, I develop all my Org-mode tools with Python which I am
comfortably with. I have done various things and put it on
http://github.com/novoid

I agree that implementing this stuff in ELISP would have been better
for the community. However, as long as I don't have an ELISP
code-monkey that implements my ideas and wishes, I have to stick to
Python which is doing well to me and I don't have to invest a couple
of weeks/months of not being that productive. You don't have to
forget that I am not a programmer - I am an advanced user who
is tweaking his personal set-up in a small sub-set of his spare
time.

If the features of my tools are implemented in Org-mode as well, I
feel happy about it. I don't want to write "please add this highly
sophisticated feature to Org-mode"-messages on the ML and wait for
somebody to implement it. I can do it on my own (in Python) and I am
able to do it the way I need/want and I am able to *use* it right
away. Works for me.

Additionally, I would never be able to implement Memacs (see sig)
without the help of several students of mine. And here is the next
thing: I could get several students with Python-knowledge and no
one(!) with (E)LISP knowledge. Sad but true. I have the feeling that
ELISP knowledge is found only at a small set of experts.

Therefore: I did it in Python and I am aware that this is not the
best thing to do. However, if somebody finds my stuff handy, she/he
can grab it from github. If somebody re-implements it in ELISP, I am
fine as well.

It is even "worse" than that: I totally insist on writing a complete
stand-alone blog system which parses my Org-mode files and generates
(static) HTML5: https://github.com/novoid/lazyblorg Bam! Worst case
scenario! :-)

I tried to get other people infected with my thoughts [1] on a IMHO
perfect blog system. So far, it seems that everybody is happy with
the blog generating systems we do have now.

When I stick to my current development velocity of lazyblorg, it
will be finished right for the Christmas season ... of 2014 ;-)

> I have to admit the org-contacts format is pretty much ad-hoc and
> not really well designed.  It is documented a bit in the file
> itself (contrib/lisp/contacts.el).  M-x customize-group RET
> org-contacts RET should also tell you more about the options.

Thanks for the pointer.

However, I consider my template a bit more elaborated since I want
to differ things like, e.g., mobile phone, work phone, land-line
phone, and so forth.

> Your format choice is not fully compatible with the existing
> org-contacts.  Right now multiple entries are separated by space
> (which sadly breaks for addresses) and different entry names are
> used.
>
> However I'd look forward to some new ideas and improvements.
> Right now it's not ideal solution.

I am glad to help here as well if my help is needed. The current
examples in org-contacts.el were not able to suit my personal
requirements. Therefore, I did my own definitions. In future, I will
derive my complete mailserver whitelist directly from my Org-mode
contacts and more.

  1. http://article.gmane.org/gmane.emacs.orgmode/49747/
-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: [O] Opening an Org file slowed down

[Michael Brand]

Hi Nicolas

On Sat, Nov 23, 2013 at 11:52 AM, Nicolas Goaziou  wrote:
> I pushed a fix that should halve the time,

I see this effect, thank you.

> but it will still be slow.
>
> `org-element-at-point' is linear by the number of elements before point
> in the current section. Therefore, parsing /all/ elements in a section
> will be quadratic by the number of elements in the section.

To avoid the quadratic scaling in my use case of "fileconversion" I
think fileconversion should be improved to insert the leading stars
_before_ Org mode has finished turning on. In the past org-mode-hook
was simply used but it seems to have become the wrong choice for my
purpose.

First, I have an understanding question:

I tried to find where org-mode-hook is called within the function
org-mode but could not see something similar to the expected
"(run-hooks 'org-mode-hook)". So I added 'backtrace to the
org-mode-hook but don't understand it either:

(backtrace)
  backtrace()
  run-hooks(change-major-mode-after-body-hook text-mode-hook
outline-mode-hook org-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook
text-mode-hook outline-mode-hook org-mode-hook))
  run-mode-hooks(org-mode-hook)
  org-mode()
  [...]

I see the expected "run-mode-hooks(org-mode-hook)" in this backtrace
but where is the corresponding form in the function org-mode?

Second, I guess it is not necessary to implement something like
org-mode-early-hook but I could not find yet an existing hook. Which
hook would you recommend for inserting the leading stars?

Michael

Re: [O] [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Eric Abrahamsen  writes:

> On 11/24/13 16:31 PM, Nicolas Goaziou wrote:
>> Hello,
>>
>> Rüdiger Sonderfeld  writes:
>>
>>> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
 Anyway, I don't think this is a good idea to introduce a new syntax just
 to avoid a one-liner (or a hook, see below). Also, this would only make
 sense in few export back-ends.
>>>
>>> But is it really a new syntax or just support for an existing Emacs 
>>> convention?  See (info "(emacs) Pages").
>>>
>>> It seems like a feature which could be supported in many back-ends: LaTeX, 
>>> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.
>>
>> I do not question this.
>>
>> My point is that introducing this new syntax would bring up nothing that
>> can already be achieved using filters or hooks.
>>
>> So, is this feature a must-have? Or would a filter template in Worg more
>> appropriate in this case?
>
> It's not that everyone is desperate to have this in org proper. Putting
> it into the code base vs making a hook: my guess is the number of LOC
> would be very nearly exactly the same, and there's literally no
> practical difference in the result. When "why" and "why not" are
> perfectly balanced, it may be better to do nothing.
>
> But I think it just *feels* right, because the page delimiter already
> seems like a first-class citizen in emacs. I'll admit it's also
> partially because it's a control character. Control character! Must be
> serious programming. I also like the thought of a new org user sticking
> one in their document, exporting, and finding that org does the right
> thing.
>
> At this point, I'm pretty much neutral buoyancy on the issue, though...
>

I (as a user, so not carrying the maintenance burden of any added
feature) am in favor of having this feature in org directly.

I think many people that use some of the export functionality will need
to control page breaks at some point.  If this is not supported by org,
most of them will have (as I did until now) backend specific page breaks
in their org mode files (maybe multiple, as suggested earlier in this
thread), which is the inferior solution.

A possible argument against the filter solution is, that an org file that
relies on the presence of a filter is less portable.

And I do not agree with 'the number of LOC would be very nearly exactly
the same' as the filter has to be copy-pasted by every one who wants to
use it ;-)


So in short:  If page breaks are not in org directly many people will
end up with inferior and/or less portable org files.



- Andreas

Re: [O] More koma confusion: subject option

[Rasmus]

James Harkins  writes:

> According to [1], "#+OPTIONS: subject:nil" should suppress printing
> the #+TITLE at the top of the letter. It seems that the previous bug
> prevents the expected line "\KOMAoption{subject}{untitled}" from being
> generated.

I cannot reproduce.

> Okay... so, what if I set "#+OPTIONS: subject:untitled"? Then I get
> something like:
>
> \KOMAoption{subject}{untitled}
> \setkomavar{subject}{The title}

As expected...

> .. and LaTeX prints "The title" in bold, above the salutation.
>
> If I remove the #+TITLE line (or comment it out), then the exporter
> assumes that the title should be the file name, minus the .org
> extension. This conflicts with [1], which claims that the default
> subject is an empty string.

No.  Title in inherited from ox-latex.el and thus works exactly as in
the LaTeX backend.  I don't know if I like this, as both subject and
title is defined in scrlttr2 (the latter in inaccessible from
ox-koma-letter).

Untitled is defined in KOMA-script and you didn't appreciate it's
meaning.  Try to compare subject:titeled to untiteled.  Hint:
(un)titled governs whether it says "subject: mysubject" or
"mysubject".

I think you want to /suppress/ subject-generation.  This is archived
with #+OPTIONS: subject:nil.

Here's an example working from emacs -q and git-emacs:

#+TITLE: A simple letter
#+CLOSING: Yours truly,
#+SIGNATURE: Jane
#+OPTIONS: subject:nil

* Pre  :noexport:
#+BEGIN_SRC emacs-lisp
(require 'ox-koma-letter)
(org-koma-letter-plug-into-ox)
(add-to-list 'org-latex-packages-alist '("AUTO" "babel" nil))
#+END_SRC

* opening
compare the above with =subject:nil=

* FROM :from:
Some Street 1

* TO :to:
John Doe

–Rasmus

-- 
Don't panic!!!

[O] Show Only Diary Entries in Agenda

[Kenneth Jacker]

I'd like to toggle (hide/show) the *non*-diary entries in the agenda
view ... to basically get a quick view of my diary/calender.

'org-agenda-toggle-diary', toggles the Diary entries.  Maybe something
like 'org-agenda-toggle-nondiary'?

I tried to configure a custom agenda view, but failed ... I'm not sure
that's the way to go anyway ...

Ideas?

Thanks,
-- 
Prof Kenneth H Jacker   k...@cs.appstate.edu
Computer Science Dept   www.cs.appstate.edu/~khj
Appalachian State Univ
Boone, NC  28608  USA

Re: [O] Opening an Org file slowed down

[Nicolas Goaziou]

Hello,

Michael Brand  writes:

> First, I have an understanding question:
>
> I tried to find where org-mode-hook is called within the function
> org-mode but could not see something similar to the expected
> "(run-hooks 'org-mode-hook)". So I added 'backtrace to the
> org-mode-hook but don't understand it either:
>
> (backtrace)
>   backtrace()
>   run-hooks(change-major-mode-after-body-hook text-mode-hook
> outline-mode-hook org-mode-hook)
>   apply(run-hooks (change-major-mode-after-body-hook
> text-mode-hook outline-mode-hook org-mode-hook))
>   run-mode-hooks(org-mode-hook)
>   org-mode()
>   [...]
>
> I see the expected "run-mode-hooks(org-mode-hook)" in this backtrace
> but where is the corresponding form in the function org-mode?

It is implied by `define-derived-mode'.

> Second, I guess it is not necessary to implement something like
> org-mode-early-hook but I could not find yet an existing hook. Which
> hook would you recommend for inserting the leading stars?

I didn't look at your code, but can't you `defadvice' `org-mode'?


Regards,

-- 
Nicolas Goaziou

Re: [O] Opening an Org file slowed down

[Nicolas Goaziou]

Hello,

Bastien  writes:

> I noticed this too -- Nicolas, was the rationale for the rewrite just
> to prevent drawers to get flagged when they find themselves in source
> code blocks?  Or are there other cases the rewrite fixes?

I somehow overlooked your message.

Anyway, preventing folding in a source block (or anywhere a drawer means
nothing) is but a side-effect, but it's the most visible one.

The real goal is to slowly introduce parsing functions in code base in
order to get a better grasp of what is needed for a complete switch.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] Re: \newpage in HTML export

[Christian Moe]

Nicolas Goaziou writes:
> So, is this feature a must-have? 

No, it's not. (Just another user's ten cents.)

> Or would a filter template in Worg more appropriate in this case?

That, or showing how to make a {{{pagebreak}}} macro expanding to export
snippets. (And explaining how regular page breaks before new chapters
etc. are anyway better handled by styles in ODT and HTML-for-print.)

Yours,
Christian

Re: [O] [ANN] Improved Flyspell check

[Nicolas Goaziou]

Hello,

Eric Schulte  writes:

> Nicolas Goaziou  writes:
>
>> Hello,
>>
>> Eric Schulte  writes:
>>
>>> I've been using this since it was sent, and I haven't noticed any bad
>>> behavior.
>>
>> Thanks for the feedback.
>>
>> BTW, I tried to add `org-self-insert-command' to
>> `flyspell-delayed-commands', since `self-insert-command' belongs to
>> `flyspell-default-delayed-commands', but I didn't notice any
>> improvement. Does this change anything for you?
>>
>
> I've tried this briefly but I don't see any effect.  It seems like a
> safe default to add...

Done.

I applied a variation of the original patch (so long).


Regards,

-- 
Nicolas Goaziou

Re: [O] Agenda: open in other frame

[Fredrik]

Yes, that is what I want :-)

 Alexander Baier  wrote 

>Fredrik  writes:
>
>> When I open an agenda and push enter on a text it opens the file
>> related to the text in the same frame. Is there any way to make it
>> open it in another frame so I keep my agenda in front?
>>
>> Regards,
>>
>> Fredrik
>
>When you say "frame", do you mean what in emacs terminology is called a
>"window"?  I am asking this as pressing RET on an item in my agenda open
>the corresponding file in the same _window_, not the same _frame_.
>
>
>Regards,
>Alex
>
>

Re: [O] Agenda: open in other frame

[Alexander Baier]

[...]

>>Fredrik  writes:
>>
>>> When I open an agenda and push enter on a text it opens the file
>>> related to the text in the same frame. Is there any way to make it
>>> open it in another frame so I keep my agenda in front?
>>>
>>> Regards,
>>>
>>> Fredrik

[...]

Well, I do not know of opening a heading in the other window, but maybe
the follow-mode is something for you? In Agenda view you can turn it on
by pressing `f`.

Regards,
  Alex

Re: [O] [PATCH] org-compat: Support for getting data from Windows clipboard

[Alexander Vorobiev]

Thanks, I will try and see if it can be improved.

Regards,
Alex


On Fri, Nov 22, 2013 at 3:54 AM, Bastien  wrote:

> Hi Alexander,
>
> Alexander Vorobiev  writes:
>
> > The patch doesn't work unfortunately. I stepped through
> > x-get-selection-value in w32-common-fns.el and the correct value from
> > the clipboard gets assigned to x-last-selected-text but then the
> > function just returns nil (line 120). I would say x-last-selected
> > text needs to be used somehow.
>
> Okay.  I applied your previous patch.  Let's keep this under the radar
> and see if there is a way to improve clipboard handling for Windows.
>
> Thanks!
>
> --
>  Bastien
>

[O] Excited to Join and Questions

[Justin Gordon]

Greetings fellow org-mode aficionados! First, a big thanks to all that
contributed to the project. It's one of my all-time favorite tools.

I write to you all as I'm looking for advice on help as I upgrade my blog
publishing system from the older org-mode to the current 8.x architecture.
I wrote a detailed summary of how I did this with 7.8 org-mode here:
http://www.railsonmaui.com/blog/2013/04/27/octopress-setup-with-github-and-org-mode/

That system depended on the old exporter and output HTML, rather than
markdown.

I looked into the org-octopress plugin, but that's not meeting my needs
mostly because the HTML export is not formatting my old org files as I'd
like them to.

So, I'm trying to write an extension of ox-md.el that supports extended
markdown dialects, such as kramdown and rdiscount.

I took the output from ox-md.el, and I have a small list of changes I need
to make for the output. Nicolas as offered me some tips, and suggested I
write to the group so all can benefite.

So here's my grand list of questions:

Strategy
---
What is the right approach for getting dot-org files into Octopress?
Octopress wants Markdown, but Markdown can have embedded HTML:
http://daringfireball.net/projects/markdown/syntax#html
The key consideration is that there must be a blank line before and after
the block-level HTML block (div, table, pre, p, etc.) in Markdown. I'd like
to make it as easy as possible to support liquid templates, as that's a key
part of Octopress. What's the least maintenance in the long run? What's
simplest? I'm guessing that Markdown conversion for the basic syntax with a
fallback to HTML for lesser supported org-elements.

Debugging and Development Tips for Org-Mode?

1. What are the best links with development advice?
2. What's the best workflow for developing a new exporter? For example,
I've got a small test file that demonstrates the formatting change I'm
trying to implement. I compile my ox-md-ext.el file for edebug mode, and
then I run the code, checking the output and maybe debugging.
3. Related to #2, is there any example of tests that verify the conversion
of input files into output files? Like could I create a few examples of org
code and create some examples of the expected octopress enabled markdown
that should be generated?

Code is where?
---
Where is the code that formats lines to say 80 chars in the ox-md
conversion? It's breaking up markdown link text with \n.

Thanks in advance for any advice.

Justin Gordon
www.railsonmaui.com | twitter: @railsonmaui
 | sugarranchmaui.com  | Sugar Ranch
Blog

[O] Trying to run tests

[Justin Gordon]

When I download the maint branch, and I run

make up2

The job never finishes. Here's the last part of the console output.

Any advice?

executing Python code block...
Wrote
/var/folders/rp/_k99k0pn0rsb4d3lm9l3dnjhgn/T/tmp-orgtest/ob-input-636455rl
Code block evaluation complete.
   passed  115/468  test-ob-python/colnames-yes-header-argument-again
Wrote
/var/folders/rp/_k99k0pn0rsb4d3lm9l3dnjhgn/T/tmp-orgtest/ob-input-63645FKB
Babel evaluation exited with code 1
   passed  116/468  test-ob-sh/dont-error-on-empty-results
   passed  117/468  test-ob-sh/dont-insert-spaces-on-expanded-bodies
^Cmake[1]: *** [test-dirty] Error 2
make: *** [up2] Interrupt:


Justin Gordon
www.railsonmaui.com | twitter: @railsonmaui
 | sugarranchmaui.com  | Sugar Ranch
Blog

Re: [O] Excited to Join and Questions

[Rasmus]

Hi Justin,

Justin Gordon  writes:

> Debugging and Development Tips for Org-Mode?
> 
> 1. What are the best links with development advice?

The Emacs manual is pretty good.  There's both the Emacs lisp intro
and the Emacs (lisp) manual.  Check info.

> 2. What's the best workflow for developing a new exporter? For example,
> I've got a small test file that demonstrates the formatting change I'm
> trying to implement. I compile my ox-md-ext.el file for edebug mode, and
> then I run the code, checking the output and maybe debugging.

There's now a (unit) testing framework (ERT).  Check testing/README in
org-git.

> 3. Related to #2, is there any example of tests that verify the conversion
> of input files into output files? Like could I create a few examples of org
> code and create some examples of the expected octopress enabled markdown
> that should be generated?

See above.

Hope it helps,
Rasmus

-- 
Summon the Mothership!

[O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes

[Rasmus]

Hi all,

Attached are a couple of changes to ox-koma-letter following a recent
bug report by James.

1. Minor fixes around.  The way subject-format was handled before was
   ugly.  Updated some docstrings etc.

2. better test of whether values have changed in the buffer.  I think
   Alan added this first, but the previous implementation.  I think
   it's more robust now, and it hopefully addresses James' problems
   (please test).  Basically and x-aux variable is added for all
   variables x in :option-alist with a default value "unset".  The
   value can then be tested.

   I'm still concerned about this whole in-buffer voodoo.  Not only do
   we test :email twice (sorry for keep bringing this up), but
   e.g. backaddress can only be set in buffer now:
   
  (when with-backaddress-set
(format "\\KOMAoption{backaddress}{%s}\n" (if with-backaddress "true" 
"false")))

   Perhaps this is OK, but one might have to rely on LCO files rather
   than lisp to change defaults (which I don't like).

3. When studying the KOMA manual to answer James' second question I
   came across the komavar title which is currently not supported.  I
   have added support for a separate SUBJECT keyword.  The heuristic
   is something like this (i) if title and subject are be truthful to
   the name no matter what, (ii) if only title or subject is said let
   title be subject if org-koma-letter-title-is-subject-maybe is t
   otherwise be truthful to name.
 
I have of course tested the patches here, but I would appreciate
feedback before they are applied.  There's also a number of TODOs in
the code that I would appreciate feedback on.

In 3. I would personally like to set
org-koma-letter-title-is-subject-maybe to nil by defaults, but this
would break backwards comparability for title keywords.

–Rasmus

PS: We should add a banner to the Worg tutorial that not all info is
up-to-date and that people one should as a minimum supplement it with
reading the commentary section of the file (I'm not sure whether
people do this).

-- 
Enough with the bla bla!
>From f6767ff0900fa65096ca4591b71a60516c4e71c6 Mon Sep 17 00:00:00 2001
From: Rasmus 
Date: Sun, 24 Nov 2013 17:57:37 +0100
Subject: [PATCH 1/3] Minor fixes for ox-koma-script.el

* ox-koma-letter.el (org-koma-letter-headline): Correct docstring.
(org-koma-letter-template): Insert subject before document start.
(org-koma-letter-headline): Fix spelling.
(org-koma-letter-template): Better subject handling.
---
 contrib/lisp/ox-koma-letter.el | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 240de29..e4d6f7a 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -111,11 +111,15 @@
 ;;   \[EXTRA]"))
 ;;
 ;; Then, in your Org document, be sure to require the proper class
-;; with :
+;; with:
 ;;
 ;;#+LATEX_CLASS: my-letter
 ;;
 ;; Or by setting `org-koma-letter-default-class'.
+;; You may possibly have to load (LaTeX) Babel as well e.g. by adding
+;; it to `org-latex-packages-alist',
+;;
+;;(add-to-list 'org-latex-packages-alist '("AUTO" "babel" nil))

 ;;; Code:

@@ -211,7 +215,6 @@ At this time the following values are allowed:
  - titled: add title/description to subject.
  - underlined: set subject underlined.
  - untitled: do not add title/description to subject.
- - No-export: do no insert a subject even if present.

 Please refer to the KOMA-script manual (Table 4.16. in the
 English manual of 2012-07-22)."
@@ -516,7 +519,7 @@ appropriate place."
 CONTENTS is the transcoded contents string.  INFO is a plist
 holding export options."
   ;; FIXME: instead of setq'ing org-koma-letter-special-contents and
-  ;; callying varioues stuff it might be nice to put a big let* around the templace
+  ;; callying varioues stuff it might be nice to put a big let* around the template
   ;; as in org-groff...
   (concat
;; Time-stamp.
@@ -585,7 +588,7 @@ holding export options."
(let ((with-backaddress (plist-get info :with-backaddress))
 	 (with-backaddress-set (plist-get info :with-backaddress-changed-in-buffer-p))
 	 (with-foldmarks (plist-get info :with-foldmarks))
-	 (with-foldmarks-set
+	 (with-foldmarks-set
 	  (not (string-equal (plist-get info :with-foldmarks-changed-in-buffer-p)
 			 "foldmarks-not-set")))
 	 (with-phone (plist-get info :with-phone))
@@ -601,28 +604,25 @@ holding export options."
 	(format "\\KOMAoption{fromphone}{%s}\n" (if with-phone "true" "false")))
   (when with-email-set
 	(format "\\KOMAoption{fromemail}{%s}\n" (if with-email "true" "false")
-   ;; Document start
-   "\\begin{document}\n\n"
;; Subject
(let* ((with-subject (plist-get info :with-subject))
-	  (subject-format (cond ((member with-subject '("true" "t" t)) nil)
-((stringp with-subject) (list with-subject))
-((symbolp with-subject)
- (list (symbol-name with-subject)))
-(t with-subje

Re: [O] Agenda: open in other frame

[Eric Abrahamsen]

Alexander Baier  writes:

> [...]
>
>>>Fredrik  writes:
>>>
 When I open an agenda and push enter on a text it opens the file
 related to the text in the same frame. Is there any way to make it
 open it in another frame so I keep my agenda in front?

 Regards,

 Fredrik
>
> [...]
>
> Well, I do not know of opening a heading in the other window, but maybe
> the follow-mode is something for you? In Agenda view you can turn it on
> by pressing `f`.
>
> Regards,
>   Alex

I think TAB or SPC instead of RET will do what you want -- TAB opens a
new window and switches to it, SPC opens a new window but doesn't switch.

[O] commit 5ea0228 has problem opening big org-mode file

[York Zhao]

Hi List,

I have an org-mode file that is 3230004 bytes in size. With commit "92f30ae" it
can be opened without any problem. However, with commit "5ea0228" the same file
could not be opened properly.

What I did was: I opened Dired buffer, select the file, press enter, nothing
happened and Emacs locks up, hit C-g to get out, and I noticed that the file had
actually been opened, so I just visited the buffer, this time the contents of
the file appeared, but my org-tables are not fontified at all.

Just now I tried again, this time I toggled "debug on error" on, closed the
file, and tried to open the file, again, Emacs locks up, hit C-g and my emacs
revived, again, the file had been opened, just didn't show up. So I visited the
buffer, this time my org-tables are fontified properly.

What's the problem do you think this could be?


Thanks,

York

Re: [O] commit 5ea0228 has problem opening big org-mode file

[Nick Dokos]

York Zhao  writes:

> Hi List,
>
> I have an org-mode file that is 3230004 bytes in size. With commit "92f30ae" 
> it
> can be opened without any problem. However, with commit "5ea0228" the same 
> file
> could not be opened properly.
>
> What I did was: I opened Dired buffer, select the file, press enter, nothing
> happened and Emacs locks up, hit C-g to get out, and I noticed that the file 
> had
> actually been opened, so I just visited the buffer, this time the contents of
> the file appeared, but my org-tables are not fontified at all.
>
> Just now I tried again, this time I toggled "debug on error" on, closed the
> file, and tried to open the file, again, Emacs locks up, hit C-g and my emacs
> revived, again, the file had been opened, just didn't show up. So I visited 
> the
> buffer, this time my org-tables are fontified properly.
>
> What's the problem do you think this could be?
>
>
Sounds like an infinite loop, but there isn't enough information to
determine where. Can you set debug-on-quit, try again and post the
backtrace?

Thanks,
-- 
Nick

Re: [O] Org menu change

[Alan L Tyree]

Nick Dokos writes:

> Alan L Tyree  writes:
>
>> In the Emacs menu Org -> Customize -> Expand this menu used to give a
>> complete menu of org-mode customisations which was quite helpful for an
>> amateur. Now it gives a short menu that does little more than send the
>> user to the usual Emacs customisation system.
>>


The error is being caused by my mu4e setup. It begins:

(require 'mu4e)
(require 'org-mu4e) ;; sets up links to email
(require 'org-contacts)

Eliminating the second two requires cures the problem and the 'Expand
this menu works as it should.

My mu4e and emacs 24 setup is a little unusual, so I don't know if this
is a general problem. I would like to hear from anyone using mu4e.

Thanks,
Alan


-- 
Alan L Tyree   http://www2.austlii.edu.au/~alan
Tel:  04 2748 6206 sip:172...@iptel.org