Re: [O] [BUG] hline references on left side of table formula

[Carsten Dominik]

Hi Rick,

hline-relative references on the left side of a table are currently not 
supported.  The fact that this is expanded is a bug.  A patch catching this 
case would be very welcome.

Regards

- Carsten

On May 1, 2013, at 7:27 PM, Rick Frankel  wrote:

> Hi-
> 
> I don't know if this is a bug or feature :), but if an hline reference
> (@I, etc) is used on the left side of a calculation, it applies to ALL
> columns in the row even if the column is specfied.
> 
> Here are some examples to show the results. I would expect all three
> versions to generate the same results as the first example.
> 
> #+BEGIN_ORG
>  * Absolute reference (expected results)
>| a | b |
>|---+---|
>| x | 1 |
>| y | 2 |
>|---+---|
>|   | 3 |
>  #+TBLFM: @4$2=vsum(@I..@II)
> 
>  * hline reference
>| a | b |
>|---+---|
>| x | 1 |
>| y | 2 |
>|---+---|
>| x + y | 3 |
>  #+TBLFM: @II$2=vsum(@I..@II)
> 
>  * hline reference with full cell specification in sum
>| a | b |
>|---+---|
>| x | 1 |
>| y | 2 |
>|---+---|
>| 3 | 3 |
>  #+TBLFM: @II$2=vsum(@I$2..@II$2)
>  #+END_ORG
> 
> FWIW, I believe the problem is that `org-table-recalculate' is
> matching lhs cell references explicitly against pure numeric
> references ("@[0-9]+$[0-9]+") and therefore expands the lhs via
> `org-expand-lhs-ranges' instead of expanding it with
> `org-table-get-descriptor-line'
> 
> rick
> 
> 

Re: [O] table.el complex tables and orgtbl-to-latex

[Carsten Dominik]

Hi Uwe,

this sounds interesting - would you be interested to provide a patch to this 
effect?

- Carsten

On May 25, 2013, at 6:35 PM, Uwe Brauer  wrote:

> 
> Hello 
> 
> As I described in a previous message, org-export can successfully export
> complex table which I have partially generated (end edited) by table.el
> into latex. 
> 
> However orgtbl-to-latex cannot not deal with such tables.
> 
> 
> Given the successful org-export function could orgtbl-to-latex be
> modified to include that feature?
> 
> thanks
> 
> Uwe Brauer 
> 
> 

Re: [O] [Feature request] Add :export option to ox-bibtex.el

[Carsten Dominik]

Hi everyone,

I have not followed the bibtex discussion in the last year or two.  Is there 
anyone who knows the latest status and who can answer this question by Feng Shu?

Thank you very much.

- Carsten

On Jul 11, 2013, at 9:20 AM, Feng Shu  wrote:

> bibtex2html can't recognize the style file in current dir (  -s 
> ./customstyle.bst ) and it can't
> deal with customize bib style file very well.
> 
> So, is it possible use different bibtex styles when I export to html?
> 
> For example:
> 
> #+BIBLIOGRAPHY: hbuuthesis plain  limit:t  option:-i export:html
> \bibliographystyle{customstyle}
> \bibliography{foo}
> 
> or:
> 
> #+BIBLIOGRAPHY: hbuuthesis plain  limit:t  option:-i export:html
> #+BIBLIOGRAPHY: hbuuthesis customstyle  limit:t  option:-i export:latex

Re: [O] [bug] orgtbl-mode conflicts with ecomplete (a address completion of mesaage mode)

[Carsten Dominik]

Hi Gregor,

thank you for your report.

I have now documented this problem in the manual, but I invite you or anyone 
else to submit a patch that will solve this issue.

- Carsten

On Sep 1, 2013, at 12:42 AM, Gregor Zattler  wrote:

> Dear org-mode Developers,
> 
> i followed the advice in the org-mode manual to use orgtbl-mode
> in message-mode buffers (see: (info "(org)Orgtbl mode") or
> [[info:org#Orgtbl%20mode][info:org#Orgtbl mode]] ), this is nice.
> 
> Since today i also want to use "ecompletion" for addresses in
> email headers in message-mode as described in 
> (info "(message)Mail Aliases") or
> [[info:message#Mail%20Aliases][info:message#Mail Aliases]].
> 
> Sadly orgtbl-mode somehow disables ecomplete.  Without
> orgtbl-mode if one types a part of an email address in an address
> header line ecomplete shows list of possible addresses which is
> shrinking while one types.  This does not happen if orgtbl-mode
> is enabled.
> 
> How to reproduce:
> 
> 1) save the attached file to ~/.ecompleterc
> 
>   be sure not to overwrite your own ~/.ecompleterc!
> 
> 2) do
> 
>   emacs -q -nw --eval "(setq message-mail-alias-type 'ecomplete)" --eval 
> '(message-mail)'
> 
>   cursor is in the To: -address header.  
> 
> 2a) type "e" 
> 
>minibuffer shows three matching addresses.  These are narrowed
>down while you type "c" "h" "o".  You might chosse one of the
>matching addresses with M-n RET.
> 
> 2b) kill Emacs.
> 
> 3) do instead:
> 
>   emacs -q -nw --eval "(setq message-mail-alias-type 'ecomplete)" --eval 
> "(add-hook 'message-mode-hook 'turn-on-orgtbl)" --eval '(message-mail)'
> 
>   cursor is in the To: -address header.  
> 
> 3a) type "e" 
> 
>minimuffer shows nothing...
> 
> 
> 3b) kill Emacs.
> 
> 
> 
> It would be great if this conflict could be fixed.  Otherwise the
> conflict could be documented in the Conflicts section of Org-mode
> (info "(org)Conflicts") or [[info:org#Conflicts]] like this:
> 
> --- org.texi2013-09-01 00:41:15.125828086 +0200
> +++ org.texi-Orgtbl-ecomplete-conflict-documented   2013-09-01 
> 00:40:56.101430317 +0200
> @@ -16414,6 +16414,18 @@
> to have other replacement keys, look at the variable
> @code{org-disputed-keys}.
> 
> +@item @file{ecomplete.el} by Lars Magne Ingebrigtsen @email{larsi@@gnus.org}
> +@cindex @file{ecomplete.el}
> +
> +Ecomplete provides ``electric'' address completion in address header
> +lines in message buffers.  Sadly Orgtbl mode cuts ecompletes power
> +supply: No completion happens when Orgtbl mode is enabled in message
> +buffers while entering text in address header lines.  If one wants to
> +use ecomplete one should @emph{not} follow the advice to automagically
> +turn on Orgtbl mode in message buffers (see @ref{Orgtbl mode}), but
> +instead---after filling in the message headers---turn on Orgtbl mode
> +manually when needed in the messages body.
> +
> @item @file{filladapt.el} by Kyle Jones
> @cindex @file{filladapt.el}
> 
> 
> 
> 
> Thanks for your attention, Gregor
> <.ecompleterc.txt>

[O] bug#14605: bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Carsten Dominik]

On Sep 2, 2013, at 10:34 AM, Jambunathan K  wrote:

> Carsten Dominik  writes:
> 
>> They are basically the "open" commands for MacOS X and Windows, and
>> mailcap for Unix/Linux.
> 
> The suggestion below is met with some approval in the Orgmode mailist
> earlier.  
> 
> http://lists.gnu.org/archive/html/emacs-orgmode/2013-07/msg00407.html
> 
> Here I go.
> 
> 
> Turn `org-file-apps-defaults-gnu' (which is now a defconst) in to
> defcustom and make xdg-open the default (or make a drop down list with
> gnome-open, kde-open for people who don't have xdg-utils insalled) .
> 
>(defconst org-file-apps-defaults-gnu
>  '((remote . emacs)
>(system . mailcap)
>(t . mailcap))
>  "Default file applications on a UNIX or GNU/Linux system.
>See `org-file-apps'.")
> 
> 
>(custom-set-variables
> '(org-file-apps
>   (quote
>((auto-mode . emacs)
> ("\\.mm\\'" . default)
> ("\\.x?html?\\'" . default)
> ("\\.pdf\\'" . default
> '(org-file-apps-defaults-gnu
>   (quote
>((remote . emacs)
> (system . "xdg-open %s")
> (t . mailcap))) t))
> 


I have not followed the discussion earlier.  The problem I see is that I do not 
know how widely available these commands are on Linux.  Maybe we can built the 
default value using executable-find or something like this?

- Carsten

> 
> 
> Anyways, opening a file outside of Emacs is not specific to Org.  Other
> applications can open facility, if available right within Emacs core.
> 
> For some discussion surrounging - `open-file' - see
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14110

[O] bug#14605: bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Jambunathan K]

Carsten Dominik  writes:

> They are basically the "open" commands for MacOS X and Windows, and
> mailcap for Unix/Linux.

The suggestion below is met with some approval in the Orgmode mailist
earlier.  

http://lists.gnu.org/archive/html/emacs-orgmode/2013-07/msg00407.html

Here I go.


Turn `org-file-apps-defaults-gnu' (which is now a defconst) in to
defcustom and make xdg-open the default (or make a drop down list with
gnome-open, kde-open for people who don't have xdg-utils insalled) .

(defconst org-file-apps-defaults-gnu
  '((remote . emacs)
(system . mailcap)
(t . mailcap))
  "Default file applications on a UNIX or GNU/Linux system.
See `org-file-apps'.")


(custom-set-variables
 '(org-file-apps
   (quote
((auto-mode . emacs)
 ("\\.mm\\'" . default)
 ("\\.x?html?\\'" . default)
 ("\\.pdf\\'" . default
 '(org-file-apps-defaults-gnu
   (quote
((remote . emacs)
 (system . "xdg-open %s")
 (t . mailcap))) t))



Anyways, opening a file outside of Emacs is not specific to Org.  Other
applications can open facility, if available right within Emacs core.

For some discussion surrounging - `open-file' - see
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14110

Re: [O] [patch][org-entities] More symbols

[Jambunathan K]

Rasmus

It seems you have a keen interest in latex + org-entities.

(This might be familiar to you.)  

You can do a,

C-x b *scarath*
C-x C-m C-\ TeX
C-h C-\ RET

and pull all the entities that you ever want in a single go (rather than
including them piecemeal-by-piecemeal.)

With some scripting, this pulling can be made less laborious but more
complete.

This is just a note.  Nothing beyond that.

Re: [O] export tex file to different directory

[Jambunathan K]

Johannes Rainer  writes:

> Hi all,
>
> is there a way that I could export the generated tex files to a
> different directory upon export?

It is called publishing.  Search the info or pdf manual.

>
> thanks, jo

Re: [O] bug#14605: bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Suvayu Ali]

Hi Carsten,

On Mon, Sep 02, 2013 at 10:44:39AM +0200, Carsten Dominik wrote:
> 
> On Sep 2, 2013, at 10:34 AM, Jambunathan K  wrote:
> 
> > '(org-file-apps-defaults-gnu
> >   (quote
> >((remote . emacs)
> > (system . "xdg-open %s")
> > (t . mailcap))) t))
> > 
> 
> 
> I have not followed the discussion earlier.  The problem I see is that
> I do not know how widely available these commands are on Linux.  Maybe
> we can built the default value using executable-find or something like
> this?

I think I can shed some light on the availability of xdg-open.  It is
provided by xdg-utils, part of the freedesktop specification.  It is
expected to be present in most desktop systems (almost anything with a
GUI installed).  It is a direct dependency for kde-libs, gnome-libs, and
many desktop applications.

The introduction in this Archlinux wiki page gives a very succint
summary: 

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

[O] bug#14605: bug#14605: bug#14605: bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Carsten Dominik]

On Sep 2, 2013, at 11:47 AM, Suvayu Ali  wrote:

> Hi Carsten,
> 
> On Mon, Sep 02, 2013 at 10:44:39AM +0200, Carsten Dominik wrote:
>> 
>> On Sep 2, 2013, at 10:34 AM, Jambunathan K  wrote:
>> 
>>>'(org-file-apps-defaults-gnu
>>>  (quote
>>>   ((remote . emacs)
>>>(system . "xdg-open %s")
>>>(t . mailcap))) t))
>>> 
>> 
>> 
>> I have not followed the discussion earlier.  The problem I see is that
>> I do not know how widely available these commands are on Linux.  Maybe
>> we can built the default value using executable-find or something like
>> this?
> 
> I think I can shed some light on the availability of xdg-open.  It is
> provided by xdg-utils, part of the freedesktop specification.  It is
> expected to be present in most desktop systems (almost anything with a
> GUI installed).  It is a direct dependency for kde-libs, gnome-libs, and
> many desktop applications.

I just love it when someone give such a concrete and useful answer.  Thank you!

- Carsten

> 
> The introduction in this Archlinux wiki page gives a very succint
> summary: 
> 
> Hope this helps,
> 
> -- 
> Suvayu
> 
> Open source is the future. It sets us free.
> 
> 
> 

Re: [O] export tex file to different directory

[Johannes Rainer]

thanks, I will give it a try.


On Sun, Sep 1, 2013 at 8:47 PM, Suvayu Ali wrote:

> On Sun, Sep 01, 2013 at 07:58:42PM +0200, Johannes Rainer wrote:
> > Hi all,
> >
> > is there a way that I could export the generated tex files to a different
> > directory upon export?
>
> If you are using subtree export, you can set the EXPORT_FILE_NAME
> property to dir/file.pdf.  If you are exporting the whole file, take a
> look at the publishing facility in the manual.
>
> Hope this helps,
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
>

[O] bug#14605: bug#14605: bug#14605: bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Carsten Dominik]

Hi everyone,

OK, we now use xdg-open when available on a Linux system.

Thanks to everyone for the input.

- Carsten

On Sep 2, 2013, at 11:47 AM, Suvayu Ali  wrote:

> Hi Carsten,
> 
> On Mon, Sep 02, 2013 at 10:44:39AM +0200, Carsten Dominik wrote:
>> 
>> On Sep 2, 2013, at 10:34 AM, Jambunathan K  wrote:
>> 
>>>'(org-file-apps-defaults-gnu
>>>  (quote
>>>   ((remote . emacs)
>>>(system . "xdg-open %s")
>>>(t . mailcap))) t))
>>> 
>> 
>> 
>> I have not followed the discussion earlier.  The problem I see is that
>> I do not know how widely available these commands are on Linux.  Maybe
>> we can built the default value using executable-find or something like
>> this?
> 
> I think I can shed some light on the availability of xdg-open.  It is
> provided by xdg-utils, part of the freedesktop specification.  It is
> expected to be present in most desktop systems (almost anything with a
> GUI installed).  It is a direct dependency for kde-libs, gnome-libs, and
> many desktop applications.
> 
> The introduction in this Archlinux wiki page gives a very succint
> summary: 
> 
> Hope this helps,
> 
> -- 
> Suvayu
> 
> Open source is the future. It sets us free.
> 
> 
> 

Re: [O] [PATCH] Handle literal 'hline arguments passed to ruby.

[Bastien]

Hi Carsten and Rick,

Carsten Dominik  writes:

> are you a signed contributor?

yes, Rick is listed on http://orgmode.org/worg/org-contribute.html

I keep the list as up-to-date as possible.

Best,

-- 
 Bastien

Re: [O] faster agenda with properties support disabled (no org-refresh-properties)

[Bastien]

Carsten Dominik  writes:

>> Great -- could someone document this on this page?
>> http://orgmode.org/worg/agenda-optimization.html
>
> Done.

Thanks!

-- 
 Bastien

Re: [O] [patch][org-entities] More symbols

[Rasmus]

Jambunathan,

> You can do a,
>
> C-x b *scarath*
> C-x C-m C-\ TeX
> C-h C-\ RET
>
> and pull all the entities that you ever want in a single go (rather than
> including them piecemeal-by-piecemeal.)

Indeed, I use this in message buffers.  If using unicode-math (a GREAT
latex package) one should even be able to use TeX input style in an
Org buffer.  However, cdlatex + entities is much quicker (on my system
"¨ b" (I've changed default keys) for β versus "\beta").

> With some scripting, this pulling can be made less laborious but more
> complete.

Would you be able to get the HTML entities?  Nicolas said that Org
"prefers" entity names due to encoding.  I can find the unicode number
in Emacs, but not it's name.  This is often the laborious part.

> This is just a note.  Nothing beyond that.

Thanks.

–Rasmus

-- 
You people at the NSA are becoming my new best friends!

Re: [O] [patch][org-entities] More symbols

[Rasmus]

Nicolas Goaziou  writes:

> Hello,
>
> Rasmus  writes:
>
>> Subject: [PATCH] More org-entities.
>
> Stylistic note for future patches: there should be no period at the end
> of the title.

OK, sorry.  Next time just let me know and I'll resubmit the patch.

–Rasmus

-- 
May contains speling mistake

Re: [O] [bug] g in agenda ignores restriction lock

[Bastien]

Hi Samuel,

Samuel Wales  writes:

> If I do an agenda with restriction lock set to a subtree, then g, the
> agenda will ignore the restriction lock.

I can't reproduce this.  Can you provide a recipe?

-- 
 Bastien

Re: [O] how to check/uncheck all checkboxes

[Bastien]

方俊  writes:

> The typical structure as following:
> - [-] root
>   - [ ] b
>   - [X] c
>   - [ ] d
>
> What i want is: if I toggle the root, all checkboxes, including root
> and children, toggled, no matter the children's status are.
>
> Is there native function/command do things like this?

Not from "- [-] root" but from "- [ ] b".

C-u C-u C-u C-c C-c will toggle all checkboxes.

C-u C-c C-c C-u C-c C-c  will untoggle all checkboxes.

HTH,

-- 
 Bastien

Re: [O] Daily snapshot issue

[Bastien]

Hi Jonathan,

Jonathan Leech-Pepin  writes:

> I've been attempting to update to the latest org using the daily .zip
> snapshot for several days (since Carsten rebuilt org-insert-heading).
> I don't have access to git on this computer. ELPA is blocked as well.
>
> The snapshot still reports the version as release_8.07-6-g13cb28 and
> has done so for nearly a week.

The snapshots were build from the maint branch, they are now build
from the master branch -- as "snapshot" suggests.

Thanks for pointing this,

-- 
 Bastien

[O] Passing arguments to org-table-export

[Alan Schmitt]

Hello,

I would like to export a table to CSV, but only the first two columns. I
see that the orgtbl-to-csv takes some parameters which may include
:skipcols, but I don't know how to pass these parameters to
org-table-export. Do I need to write my own function to do it?

Thanks,

Alan

Re: [O] Bug: Messaging when moving in the agenda [7.9.2 (7.9.2-GNU-Emacs-24-3 @ /usr/share/emacs/24.2.50/lisp/org/)]

[Michael Heerdegen]

Hi Carsten,

> I believe I have done it in the right place now, please confirm.

Confirmed, thanks, that's what I wanted.

There's just a little typo in the docstring of `org-unlogged-message':

"Display a message, but avoid loggin it in the *Messages* buffer."
^
g

Regards,

Michael.

Re: [O] Daily snapshot issue

[Carsten Dominik]

On Sep 2, 2013, at 1:49 PM, Bastien  wrote:

> Hi Jonathan,
> 
> Jonathan Leech-Pepin  writes:
> 
>> I've been attempting to update to the latest org using the daily .zip
>> snapshot for several days (since Carsten rebuilt org-insert-heading).
>> I don't have access to git on this computer. ELPA is blocked as well.
>> 
>> The snapshot still reports the version as release_8.07-6-g13cb28 and
>> has done so for nearly a week.
> 
> The snapshots were build from the maint branch, they are now build
> from the master branch -- as "snapshot" suggests.

Ah, yes, better.  Thank you Bastien!

- Carsten

> 
> Thanks for pointing this,
> 
> -- 
> Bastien
> 

Re: [O] [patch][org-entities] More symbols

[Rasmus]

Jambunathan K  writes:

> Rasmus  writes:
>
>>> With some scripting, this pulling can be made less laborious but more
>>> complete.
>>
>> Would you be able to get the HTML entities?  Nicolas said that Org
>> "prefers" entity names due to encoding.  I can find the unicode number
>> in Emacs, but not it's name.  This is often the laborious part.
>
> Why use name when it is easier to use the numerical value?  

Don't know.  Here's a quote from earlier.  I personally didn't look
further into it.

>> I wrote:
>> 2. HTML symbols have been tested in Firefox.  In a few cases I
>>couldn't find a pretty name (like "π") in which case I've
>>supplied the unicode number (like "&960;").  Is that OK?  (E.g. can
>>Org produce non-uft8 HTML?)

> Nicolas wrote:
> I think it can: see `org-html-coding-system'. It may be wiser to avoid
> these symbols altogether.



> Something like — should be good for —.  (You can get the code
> value by doing the C-u C-x = on the displayed character.)

Irrespective of encoding?

> ,
> |   character: — (displayed as —) (codepoint 8212, #o20024, #x2014)
> |   ^^
> |   name: EM DASH
> `
>
> 
>
> I see that the entity names are listed in
> http://www.w3.org/TR/xml-entity-names/byalpha.html

Right.

Are we having (huge) gaps somewhere worth fixing?

–Rasmus

-- 
This space is left intentionally blank

Re: [O] [PATCH] Center currently clocked headline to top of screen

[Sebastien Vauban]

Hi Carsten, Daniel and all,

Carsten Dominik wrote:
>> El Thu, 22 Aug 2013 10:36:00 +0200 Sebastien Vauban va escriure:
>>
>>> When jumping to the currently clocked headline (via `C-c C-x C-j'), it
>>> seems (to me) more logical to recenter that headline at the top of the
>>> screen (vs at the center of the screen, that is the current behavior).
>
>> Seeing a bit of context is nice; maybe putting it at line 2 or 3 is better
>> than at the top and I think it is better than centered. It could also be
>> configurable.
>
> Yup, I have made this a (recenter 2). Non-configurable until arrival of more
> votes.

I'd vote for (recenter 0), as:

- I generally only clock on projects, and

- I'm not interested by seeing the last action(s) of the previous project,
  when jumping to the currently clocking task.

May I submit a patch with a configurable variable?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [PATCH] Handle literal 'hline arguments passed to ruby.

[Carsten Dominik]

On Sep 2, 2013, at 12:54 PM, Bastien  wrote:

> Hi Carsten and Rick,
> 
> Carsten Dominik  writes:
> 
>> are you a signed contributor?
> 
> yes, Rick is listed on http://orgmode.org/worg/org-contribute.html
> 
> I keep the list as up-to-date as possible.

And I do look there, but looked in the wrong place.  Thanks.

- Carsten

> 
> Best,
> 
> -- 
> Bastien

Re: [O] [PATCH] Handle literal 'hline arguments passed to ruby.

[Carsten Dominik]

Applied, thank.

Rick, I had trouble applying th patch, so did some handywork - please check 
after me.

Thank you!

- Carsten

On Aug 15, 2013, at 8:50 PM, Rick Frankel  wrote:

> Solution shamelessly copied from ob-python.
> 
> * lisp/ob-ruby.el: New customizations `org-babel-ruby-hline-to' and
> `org-babel-ruby-nil-to'
> (org-babel-ruby-var-to-ruby): Convert incoming 'hlines.
> (org-babel-ruby-table-or-string): Convert outgoing nils.
> ---
> lisp/ob-ruby.el | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
> index 20fb418..d15d288 100644
> --- a/lisp/ob-ruby.el
> +++ b/lisp/ob-ruby.el
> @@ -50,6 +50,20 @@
> (defvar org-babel-ruby-command "ruby"
> "Name of command to use for executing ruby code.")
> 
> +(defcustom org-babel-ruby-hline-to "nil"
> +  "Replace hlines in incoming tables with this when translating to ruby."
> +  :group 'org-babel
> +  :version "24.4"
> +  :package-version '(Org . "8.0")
> +  :type 'string)
> +
> +(defcustom org-babel-ruby-nil-to 'hline
> +  "Replace 'nil' in ruby tables with this before returning."
> +  :group 'org-babel
> +  :version "24.4"
> +  :package-version '(Org . "8.0")
> +  :type 'string)
> +
> (defun org-babel-execute:ruby (body params)
> "Execute a block of Ruby code with Babel.
> This function is called by `org-babel-execute-src-block'."
> @@ -115,13 +129,21 @@ Convert an elisp value into a string of ruby source code
> specifying a variable of the same value."
> (if (listp var)
> (concat "[" (mapconcat #'org-babel-ruby-var-to-ruby var ", ") "]")
> -(format "%S" var)))
> +(if (equal var 'hline)
> + org-babel-ruby-hline-to
> +  (format "%S" var
> 
> (defun org-babel-ruby-table-or-string (results)
> "Convert RESULTS into an appropriate elisp value.
> If RESULTS look like a table, then convert them into an
> Emacs-lisp table, otherwise return the results as a string."
> -  (org-babel-script-escape results))
> +  ((lambda (res)
> + (if (listp res)
> +  (mapcar (lambda (el) (if (equal el 'nil)
> +   org-babel-ruby-nil-to el))
> +  res)
> +   res))
> +   (org-babel-script-escape results)))
> 
> (defun org-babel-ruby-initiate-session (&optional session params)
> "Initiate a ruby session.
> -- 
> 1.8.0
> 
> 

Re: [O] require a feature: merge many contacts which have the same name.

[Feng Shu]

Hello, Daimrod

I remember that  you have mailed  me a elisp function which can merge contacts,
but now I can't find this function, so could you resend it to me ?  

Thanks!


--- Feng shu

Re: [O] [PATCH] Center currently clocked headline to top of screen

[Carsten Dominik]

On Sep 2, 2013, at 4:02 PM, Sebastien Vauban  wrote:

> Hi Carsten, Daniel and all,
> 
> Carsten Dominik wrote:
>>> El Thu, 22 Aug 2013 10:36:00 +0200 Sebastien Vauban va escriure:
>>> 
 When jumping to the currently clocked headline (via `C-c C-x C-j'), it
 seems (to me) more logical to recenter that headline at the top of the
 screen (vs at the center of the screen, that is the current behavior).
>> 
>>> Seeing a bit of context is nice; maybe putting it at line 2 or 3 is better
>>> than at the top and I think it is better than centered. It could also be
>>> configurable.
>> 
>> Yup, I have made this a (recenter 2). Non-configurable until arrival of more
>> votes.
> 
> I'd vote for (recenter 0), as:
> 
> - I generally only clock on projects, and
> 
> - I'm not interested by seeing the last action(s) of the previous project,
>  when jumping to the currently clocking task.
> 
> May I submit a patch with a configurable variable?

Yes.

- Carsten

> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 

[O] csv and vcf export about org-contacts.el

[Feng Shu]

Recently, I have found a android app (customer contacts) which can quickly 
search contacts
(csv format), so I hack a csv exporter based the vcf exporter's code, does 
org-contacts
need a csv exporter default?



-- Feng Shu

-- 

Re: [O] how to check/uncheck all checkboxes

[方俊]

It does not work in my orgmode 8.0.7 in emacs 24.3, prompting an error:
unchecked subitems.
but thank you all the same.

PS: Google tasks does exactly what I described.


On Mon, Sep 2, 2013 at 7:38 PM, Bastien  wrote:

> 方俊  writes:
>
> > The typical structure as following:
> > - [-] root
> >   - [ ] b
> >   - [X] c
> >   - [ ] d
> >
> > What i want is: if I toggle the root, all checkboxes, including root
> > and children, toggled, no matter the children's status are.
> >
> > Is there native function/command do things like this?
>
> Not from "- [-] root" but from "- [ ] b".
>
> C-u C-u C-u C-c C-c will toggle all checkboxes.
>
> C-u C-c C-c C-u C-c C-c  will untoggle all checkboxes.
>
> HTH,
>
> --
>  Bastien
>



-- 
方俊

Re: [O] Using org-goto loses org-todo-keyword-faces settings

[Dale]

How surprising!  I just confirmed this again by installing Emacs 24.3
release from MacPorts, running emacs -Q in a terminal Emacs, loading
org-mode from Git, and opening the below org file, making sure to
accept the "unsafe" file local setting of org-todo-keyword-faces.  I
was able to reproduce it: WAITING was orange before org-goto, default
red after org-goto.

Now I wonder what's different about my setup!

Oh well, thanks anyway for looking at this.  For the time being I've
just added after advice to org-goto to run (font-lock-fontify-buffer),
which restores my colors when I exit org-goto.

Regards,
Dale


On Mon, Sep 2, 2013 at 12:42 AM, Carsten Dominik
 wrote:
> Hi Dale,
>
> thank you for the report and detailed example.  I have followed your recipe 
> and cannot reproduce the issue.
>
> Regards
>
> - Carsten
>
> On 21.8.2013, at 02:25, Dale  wrote:
>
>> Hi,
>>
>>   My thanks to everyone who works on org-mode.  It is a truly 
>> indispensable tool.
>>
>>   I'm not sure if I have a bug or a feature request: I have custom faces 
>> set up for my todo keywords (see my file local variable for 
>> org-todo-keyword-faces at the bottom of this report).   When I use org-goto 
>> (C-c C-j) and then exit goto mode, my custom colors for todo keywords are 
>> reset to the defaults.
>>
>>   Explicitly:
>>
>> 1. Create and save an org file with the following contents:
>>
>> --8<--Cut here--8<--
>> * WAITING test1
>>
>> #+TODO: NEW(n) PENDING(p!) WAITING(w!) HOLD(h!) | DONE(d!) CANCELLED(c!)
>>
>> # Local Variables:
>> # org-todo-keyword-faces: (("WAITING" . "dark orange")
>> #  ("HOLD" . "dark orange"))
>> # End:
>> --8<--Cut here--8<--
>>
>> 2. Revert the buffer to pick up the in-buffer configuration including file 
>> local variables.
>>
>> 3. C-c C-j followed by C-g to exit goto mode.
>>
>> What I expected: WAITING would still be "dark orange" when I exit goto mode.
>>
>> What I observed: WAITING reverts to the default red color when I exit goto 
>> mode.
>>
>> (WAITING is also red while I'm in org-goto mode, which is less of a problem 
>> for me.  I'd be happy enough if the color was just restored when I'm done 
>> with org-goto.)
>>
>>   I would, of course, be grateful if my org-todo-keyword-faces would 
>> still be respected after using goto mode.
>>
>>   I am using Emacs 24.3.1, apparently, the unofficial Emacs Mac Port 
>> (ftp://ftp.math.s.chiba-u.ac.jp/emacs/).  I just confirmed this behavior 
>> using org-mode's master branch from git://orgmode.org/org-mode.git as of a 
>> few minutes ago.  The output from org-submit-bug-report is below.
>>
>> Thanks for everything,
>> Dale
>>
>>
>> Emacs  : GNU Emacs 24.3.1 (x86_64-apple-darwin12.4.0, Carbon Version 1.6.0 
>> AppKit 1187.39)
>> of 2013-06-26
>> Package: Org-mode version 8.0.7 (release_8.0.7-383-g927f1b @ 
>> /Users/dale/.emacs.d/packages/org-mode/)
>>
>> current state:
>> ==
>> (setq
>> org-hide-leading-stars t
>> org-tab-first-hook '(org-hide-block-toggle-maybe
>>  org-src-native-tab-command-maybe
>>  org-babel-hide-result-toggle-maybe
>>  org-babel-header-arg-expand)
>> org-speed-command-hook '(org-speed-command-default-hook
>>  org-babel-speed-command-hook)
>> org-reverse-note-order t
>> org-time-clocksum-format "%d:%02d"
>> org-occur-hook '(org-first-headline-recenter)
>> org-metaup-hook '(org-babel-load-in-session-maybe)
>> org-agenda-todo-ignore-deadlines 'far
>> org-src-window-setup 'other-window
>> org-confirm-shell-link-function 'yes-or-no-p
>> org-agenda-todo-ignore-scheduled 1
>> org-default-notes-file "~/todo.org"
>> org-startup-indented t
>> org-after-todo-state-change-hook '(org-clock-out-if-current)
>> org-src-mode-hook '(org-src-babel-configure-edit-buffer
>> org-src-mode-configure-edit-buffer)
>> org-tags-column -76
>> org-agenda-before-write-hook '(org-agenda-add-entry-text)
>> org-babel-pre-tangle-hook '(save-buffer)
>> org-agenda-dim-blocked-tasks nil
>> org-mode-hook '(#[nil "\300\301\302\303\304$\207"
>>   [org-add-hook change-major-mode-hook org-show-block-all
>>append local]
>>   5]
>> #[nil "\300\301\302\303\304$\207"
>>   [org-add-hook change-major-mode-hook
>>org-babel-show-result-all append local]
>>   5]
>> org-babel-result-hide-spec org-babel-hide-all-hashes
>> my:org-mode-hook)
>> org-outline-path-complete-in-steps nil
>> org-agenda-todo-list-sublevels nil
>> org-replace-disputed-keys t
>> org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
>>  org-babel-execute-safely-maybe)
>> org-refile-use-outline-path t
>> org-enforce-todo-dependencies t
>> org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
>>  org-cycle-hide-inline-tasks o

Re: [O] fold paragraphs, export only contents of a node, hiding the 'node heading text'

[. .]

Thanks for your reply.

Sorry, I don't know where you should put that code to create the custom 
function!
I put it inside .emacs, restarted Emacs, but after latex export the headlines 
where visible in the resulting .tex/PDF.

I did add the bind etc. to the test-file.org like you did.


Regards,
Mark

El 02/09/2013, a las 01:51, John Hendy  escribió:

> On Sun, Sep 1, 2013 at 4:17 PM, . .  wrote:
>> Hello:
>> 
>> Is there a way to export to Latex the text under a heading but 
>> not-exporting/printing to the .tex file the heading/TODO (node line) itself?
>> 
>> The idea is to be able to fold paragraphs (via node creation for the 
>> paragraphs under it).
>> But if I set the node to noexport (to hide the unnecessary heading/TODO text 
>> which was only there to allow folding the text under it) then the paragraph 
>> can't be exported either!
>> 
>> This would be great to permit folding with great granularity and use the 
>> heading to describe the paragraph without showing it (like a comment only it 
>> folds!).
> 
> I never did dig into this as it still was a bit above my head, but it
> seems like this could do what you want:
> - https://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01329.html
> 
> In other words, you'd define a custom function like this:
> 
> (defun mapcdi-org-latex-headline-function (todo todo-type priority text tags)
> "The docstring of my function."
> (concat
>  (and todo (format "{\\bfseries\\sffamily %s} " todo))
>  (and priority (format "\\framebox{\\#%c} " priority))
>  text
>  (and tags
>   (format "\\hfill{}\\textsc{%s}" (mapconcat 'identity tags ":")
> 
> 
> I think you'd just omit that "text" bit, and probably remove the other stuff 
> to.
> 
> ETA: I just went ahead and gave it a whirl. It looks like this, or
> something close, should let you do whatever you want with headlines
> (go ahead and use priorities, tags, todo keywords, and the like and
> still just get a blank headline:
> 
> (defun mapcdi-org-latex-headline-function (todo todo-type priority text tags)
> "The docstring of my function."
> (concat
>  (and todo (format "{}" todo))
>  (and priority (format "{} " ))
> 
>  (and tags
>   (format "\\hfill{}\\textit{}" (mapconcat 'identity tags ":")
> 
> There most likely is a blank line where the headline *would* go. I
> played around with trying to \vspace a negative line space like so,
> and I think it's doing the right thing, or is at least close (there's
> less space between the contents line and the paragraph text):
> 
> (defun mapcdi-org-latex-headline-function (todo todo-type priority text tags)
> "The docstring of my function."
> (concat
>  (and todo (format "{}" todo))
>  (and priority (format "{} " ))
>  (and text (format "{\\vspace{-\\baselineskip}}" ))
>  (and tags
>   (format "\\hfill{}\\textit{}" (mapconcat 'identity tags ":")
> 
> The only thing I noticed is that within a section, paragraphs by
> default have no space and are indented (well, the first isn't, but
> following paragraphs are). With this method, paragraphs within
> sections are going to have the typical post-section spacing compared
> to being treated like truly consecutive paragraphs. If you're okay
> with that, then this will work. If not, you'll have to make a custom
> latex template somehow so that the whole document is treated like one
> long section. I'm not sure if that's possible given org's headline ->
> section internals. You might be able to fiddle with something like the
> above \vspace{} trick, though? You'd also have to have every paragraph
> indented so that they weren't treated like the first paragraph in a
> section (un-indented).
> 
> Anyway, hopefully this gets you on the right path!
> 
> #+begin_src test-file
> 
> #+bind: org-latex-format-headline-function mapcdi-org-latex-headline-function
> #+options: num:nil
> 
> * todo headline 1   :test:
> 
> blah blah blah.
> 
> * headline 2
> 
> blah blah blah
> 
> * headline 3
> 
> A couple of separate paragraphs to see how far apart two paragraphs would be
> normally. We'll add enough to line break just to make it interesting.
> 
> A couple of separate paragraphs to see how far apart two paragraphs would be
> normally. We'll add enough to line break just to make it interesting.
> 
> #+end_src
> 
> 
> 
> Best regards,
> John
> 
> 
> 
>> 
>> Thanks,
>> Best regards,
>> Mark

Re: [O] skip:t option not working

[Scott Randby]

On 09/02/2013 01:47 AM, Carsten Dominik wrote:
>
> On 10.8.2013, at 20:46, Scott Randby  wrote:
>
>> On 08/10/2013 02:00 PM, Nick Dokos wrote:
>>> Scott Randby  writes:
>>>
 On 08/09/2013 10:58 PM, Nick Dokos wrote:
> Scott Randby  writes:
>
>> I cannot get the skip:t option to work with HTML export. This option is
>> listed in the manual, and it worked before Org-8. Am I missing
>> something? Below is a simple sample in which skip:t doesn't work, even
>> with emacs -q. I'm using Emacs 24.2.1 with Org 8.0.3.
>>
>
> I don't think it exists any longer.
>

 If the option no longer exists, then it might be a good idea to remove
 it from the manual.

>>>
>>> Indeed, but afaict, it's no longer in the current (8.0.7) manual. Are
>>> you looking at an older version of the manual perhaps? I might have
>>> missed the reference of course, in which case if you post the details,
>>> somebody will fix it.
>>>
>>
>> You can find a reference to the skip option on this page:
>>
>> http://orgmode.org/manual/Export-options.html
>>
>> It seems that this is the old 12.2 page, but it still links up to the
>> 8.0.7 manual. No wonder I've been confused. The correct 12.2 page is
>> given by this link:
>>
>> http://orgmode.org/manual/Export-back_002dends.html#Export-back_002dends
>>
>> The current export options (which I missed before) are now in section 12.3:
>>
>> http://orgmode.org/manual/Export-settings.html#Export-settings
>>
>> I think the website needs to be cleaned up a bit.
>
> Is this still an issue?

The following page still exists on the website:

  http://orgmode.org/manual/Export-options.html

Its title is "12.2 Export options" and the "Up" navigation link
(http://orgmode.org/manual/Exporting.html#Exporting) on the page leads
to the "Exporting" page (section 12) of the current manual.

In the current manual, section 12.2 is "Export back-ends."

Scott Randby

[O] bug#14605: bug#14605: bug#14605: bug#14605: bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Torsten Wagner]

Hi Carsten,
just by chance I read this thread.

It might be a good idea to announce this somehow for package maintainers on
a prominent place in the change-log of the next official release. Some
Linux package systems do allow recommendation on packages.
As I understood the xdg-utils package is not mandatory for using org-mode,
because it would work without xdg-open too. However, we could ask the
package maintainers to make a recommendation to install xdg-util whenever,
org-mode gets installed. Just a nice customer service ;)

BTW: Emacs itself does *not* require xdg-utils or refer to it as optional.
That would have made it even easier to assume it is already on all Linux
systems.

All the best

Torsten



On 2 September 2013 12:08, Carsten Dominik wrote:

> Hi everyone,
>
> OK, we now use xdg-open when available on a Linux system.
>
> Thanks to everyone for the input.
>
> - Carsten
>
> On Sep 2, 2013, at 11:47 AM, Suvayu Ali 
> wrote:
>
> > Hi Carsten,
> >
> > On Mon, Sep 02, 2013 at 10:44:39AM +0200, Carsten Dominik wrote:
> >>
> >> On Sep 2, 2013, at 10:34 AM, Jambunathan K 
> wrote:
> >>
> >>>'(org-file-apps-defaults-gnu
> >>>  (quote
> >>>   ((remote . emacs)
> >>>(system . "xdg-open %s")
> >>>(t . mailcap))) t))
> >>>
> >>
> >>
> >> I have not followed the discussion earlier.  The problem I see is that
> >> I do not know how widely available these commands are on Linux.  Maybe
> >> we can built the default value using executable-find or something like
> >> this?
> >
> > I think I can shed some light on the availability of xdg-open.  It is
> > provided by xdg-utils, part of the freedesktop specification.  It is
> > expected to be present in most desktop systems (almost anything with a
> > GUI installed).  It is a direct dependency for kde-libs, gnome-libs, and
> > many desktop applications.
> >
> > The introduction in this Archlinux wiki page gives a very succint
> > summary: 
> >
> > Hope this helps,
> >
> > --
> > Suvayu
> >
> > Open source is the future. It sets us free.
> >
> >
> >
>
>
>
>
>

Re: [O] [BUG] [Babel] Do not try to process inline source in macro templates

[Eric Schulte]

Nicolas Girard  writes:

> When a buffer contains such
>
> #+MACRO: m src_emacs-lisp[:results raw]{(do-something "$1")}
>
> macro template, calling =org-babel-execute-buffer= using =C-c C-v C-b= yields
>
> if: No id found: $1
>
> It seems to me that Babel shouldn't be looking for inline code within
> macro templates.
>

I've just pushed up a fix for this issue which should now ignore inline
source blocks on lines starting with "#+" during export.  I don't know
if there is a better way than using a regex to detect such non-exporting
lines but this appears to work.

Cheers,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] [BUG] [Babel] Do not try to process inline source in macro templates

[Carsten Dominik]

Thank you Eric.

- Carsten

On 2.9.2013, at 18:35, Eric Schulte  wrote:

> Nicolas Girard  writes:
> 
>> When a buffer contains such
>> 
>>#+MACRO: m src_emacs-lisp[:results raw]{(do-something "$1")}
>> 
>> macro template, calling =org-babel-execute-buffer= using =C-c C-v C-b= yields
>> 
>>if: No id found: $1
>> 
>> It seems to me that Babel shouldn't be looking for inline code within
>> macro templates.
>> 
> 
> I've just pushed up a fix for this issue which should now ignore inline
> source blocks on lines starting with "#+" during export.  I don't know
> if there is a better way than using a regex to detect such non-exporting
> lines but this appears to work.
> 
> Cheers,
> 
> -- 
> Eric Schulte
> https://cs.unm.edu/~eschulte
> PGP: 0x614CA05D
> 

Re: [O] bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Achim Gratz]

Carsten Dominik writes:
> OK, we now use xdg-open when available on a Linux system.

The availability of xdg-open has nothing to do with whether or not you
are running Emacs on a Linux system.  Indeed, even on a system where it
is available, it won't do anything useful if you're running from a
console.  While I think it's a good default for someone using a desktop
that conforms to XDG standards, there should be a check if in fact Emacs
is running on such a desktop.


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

[O] org-capture doesn't narrow correctly if :prepend is t

[Adam Spiers]

I have an org-capture template as follows:

 ("n" "personal NEXT" entry
  (file "~/org/TODO.org")
  "* NEXT %?" :prepend t)

but after I hit `C-c C-c', the file's buffer stays narrowed, with the
new entry invisible.  Anyone who didn't notice the presence of
'Narrow' in the modeline would be convinced that the capture
completely failed.  It can be revealed via `C-u C-x n w', but of
course it's annoying having to do this every time.

The problem vanishes as soon as I de-select the :prepend flag.  It's
been an issue for a while, so I guess I'm the only one using this
flag?

Thanks!
Adam

Re: [O] Completion of `*' gives wrong number of arguments

[Dieter Wilhelm]

Carsten Dominik  writes:

> Hi Dieter,
>
> On 2.8.2013, at 16:53, "Dieter Wilhelm, H."  
> wrote:
>
>> Dear (),
>> 
>> is the completion of an asterix `*' broken in the latest org or is it
>> my configuration?
>
> This was a bug in Org mode.  WOrks again now.

Thanks a lot. The completion with C-M-i is now working but not from the
menu>:.

The last entry remains greyed...

>> 
>> (I'm sorry I still can't run a pristine Emacs -Q without loading the
>> old org mode)

Hmm, I figure that I just need to tell something like: emacs -Q --eval
'(add-to-list 'load-path "path/to/org-mode/source/dir")', right?

>> Remark: It would be wonderful if the completion of headlines would
>> also work within C-c C-l...
>
> That would be a lot more work.

OK :-|

--
   Dieter




> Regards
>
> - Carsten
>
>> 
>> Have a nice weekend
>> --
>> Best wishes
>> 
>>H. Dieter Wilhelm
>> 
>> Darmstadt
>> Germany
>> 
>

-- 
Best wishes

H. Dieter Wilhelm
Darmstadt
Germany

Re: [O] export question

[Manfred Lotz]

On Sun, 1 Sep 2013 20:50:07 +0200
Suvayu Ali  wrote:

> On Sun, Sep 01, 2013 at 06:49:01PM +0200, Manfred Lotz wrote:
> > 
> > Now I want to export the file to an ascii buffer/file where show the
> > content as a table. I want to omit certain p lines.
> > 
> > So I would like to have something like this where I would like to
> > show only certain columns.
> > 
> > 
> > 
> >  val p1 p14   
> > --
> >  item 1  something  bla   
> >  item n  hm more more bla 
> 
>  [...chomp...chomp...chomp...]
> 
> > I guess 1. makes much sense. In this case I like to know if there
> > is a tutorial showing how to do my own exporter or where to find
> > specific documentation how to do this?
> 
> ox-odt.el has a feature like this, list to tables.  You can take a
> look there for hints.
> 

Thanks for the pointer. I'll look at it.

-- 
Manfred

Re: [O] bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Carsten Dominik]

On 2.9.2013, at 18:54, Achim Gratz  wrote:

> Carsten Dominik writes:
>> OK, we now use xdg-open when available on a Linux system.
> 
> The availability of xdg-open has nothing to do with whether or not you
> are running Emacs on a Linux system.  Indeed, even on a system where it
> is available, it won't do anything useful if you're running from a
> console.  While I think it's a good default for someone using a desktop
> that conforms to XDG standards, there should be a check if in fact Emacs
> is running on such a desktop.

Hi Achim,

thanks for this input.  THis makes it more complicated.  Do you know how I 
would test this?  I do know about the variable window-system, but that will 
also return nil when Emacs is running in an xterm, even though xdg-open would 
be working in this case.

Since we are close to a release, maybe I should revert the commit for now and 
solve this with more time.

- Carsten

> 
> 
> Regards,
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
> 
> Factory and User Sound Singles for Waldorf rackAttack:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
> 
> 

Re: [O] Completion of `*' gives wrong number of arguments

[Carsten Dominik]

On 2.9.2013, at 21:51, Dieter Wilhelm  wrote:

> Carsten Dominik  writes:
> 
>> Hi Dieter,
>> 
>> On 2.8.2013, at 16:53, "Dieter Wilhelm, H."  
>> wrote:
>> 
>>> Dear (),
>>> 
>>> is the completion of an asterix `*' broken in the latest org or is it
>>> my configuration?
>> 
>> This was a bug in Org mode.  WOrks again now.
> 
> Thanks a lot. The completion with C-M-i is now working but not from the
> menu>:.
> 
> The last entry remains greyed...

This is an unrelated bug.  And nobody would use the menu for this anyway, right?
I'll put this on my list of things to fix.

Thanks!

- Carsten

> 
>>> 
>>> (I'm sorry I still can't run a pristine Emacs -Q without loading the
>>> old org mode)
> 
> Hmm, I figure that I just need to tell something like: emacs -Q --eval
> '(add-to-list 'load-path "path/to/org-mode/source/dir")', right?
> 
>>> Remark: It would be wonderful if the completion of headlines would
>>> also work within C-c C-l...
>> 
>> That would be a lot more work.
> 
> OK :-|
> 
> --
>   Dieter
> 
> 
> 
> 
>> Regards
>> 
>> - Carsten
>> 
>>> 
>>> Have a nice weekend
>>> --
>>> Best wishes
>>> 
>>>   H. Dieter Wilhelm
>>> 
>>> Darmstadt
>>> Germany
>>> 
>> 
> 
> -- 
> Best wishes
> 
> H. Dieter Wilhelm
> Darmstadt
> Germany

Re: [O] Problem with special characters in dired and attachment paths

[M]

it seems that this is a bug (or missing feature) of Emacs on MS Windows:

see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15236

Did noone else using Emacs on Windows encounter those problems?

Kind regards

Martin


> Datum: Wed, 21 Aug 2013 17:42:59 +0200 (CEST)
> An: emacs orgmode-mailinglist 
> Betreff: [O] Problem with special characters in dired and attachment paths
> 
> I'm having problems with special characters like äöü in dired mode and in
> attachment paths:
>  
> 1) When I'm trying to access a directory with M-x dired, the displayed path
> contains strange characters like e.g. "\374" for "ü" or "\366" for "ö".
> Same is true for directory and file listings displayed by dired.
>  
> Is there a setting which can make dired display the characters with the
> correct encoding?
>  
> 2) my other problem seems to be related:
> I currently added a long server path as attachment directory in org-mode, like
> //servername/dir1/dir2/dir2/dir4/etcetera/Zubehör/
> (I usually copy the UNC path in Windows 7 Explorer with the PathCopy context
> menu)
>  
> The path is shown like that in :ATTACH_DIR: in the properties with the "ö"
> correctly displayed.
> When I type C-c C-a C-f to open the directory in Windows Explorer, it creates
> a new directory at the same path called Zubehör which is opened instead of
> the right one.
>  
> How can I solve those 2 problems?
>  
> Kind regards
>  
> Martin
>  
>  

Re: [O] skip:t option not working

[Carsten Dominik]

On 2.9.2013, at 17:58, Scott Randby  wrote:

> On 09/02/2013 01:47 AM, Carsten Dominik wrote:
>> 
>> On 10.8.2013, at 20:46, Scott Randby  wrote:
>> 
>>> On 08/10/2013 02:00 PM, Nick Dokos wrote:
 Scott Randby  writes:
 
> On 08/09/2013 10:58 PM, Nick Dokos wrote:
>> Scott Randby  writes:
>> 
>>> I cannot get the skip:t option to work with HTML export. This option is
>>> listed in the manual, and it worked before Org-8. Am I missing
>>> something? Below is a simple sample in which skip:t doesn't work, even
>>> with emacs -q. I'm using Emacs 24.2.1 with Org 8.0.3.
>>> 
>> 
>> I don't think it exists any longer.
>> 
> 
> If the option no longer exists, then it might be a good idea to remove
> it from the manual.
> 
 
 Indeed, but afaict, it's no longer in the current (8.0.7) manual. Are
 you looking at an older version of the manual perhaps? I might have
 missed the reference of course, in which case if you post the details,
 somebody will fix it.
 
>>> 
>>> You can find a reference to the skip option on this page:
>>> 
>>> http://orgmode.org/manual/Export-options.html
>>> 
>>> It seems that this is the old 12.2 page, but it still links up to the
>>> 8.0.7 manual. No wonder I've been confused. The correct 12.2 page is
>>> given by this link:
>>> 
>>> http://orgmode.org/manual/Export-back_002dends.html#Export-back_002dends
>>> 
>>> The current export options (which I missed before) are now in section 12.3:
>>> 
>>> http://orgmode.org/manual/Export-settings.html#Export-settings
>>> 
>>> I think the website needs to be cleaned up a bit.
>> 
>> Is this still an issue?
> 
> The following page still exists on the website:
> 
>  http://orgmode.org/manual/Export-options.html


Indeed.  THis one and about 20 other old files still lurking there.
I have removed them now, thank you.

- Carsten


> 
> Its title is "12.2 Export options" and the "Up" navigation link
> (http://orgmode.org/manual/Exporting.html#Exporting) on the page leads
> to the "Exporting" page (section 12) of the current manual.
> 
> In the current manual, section 12.2 is "Export back-ends."
> 
> Scott Randby
> 
> 

Re: [O] org-speed-commands-default 1 2 3

[Tom Davey]

Olen writes:

> Level 2 is very useful - and cannot, unlike Level 1, be reached by S-TAB.

Actually, it can. S-TAB takes a numeric prefix key. The doc string says:

"When ARG is a numeric prefix, show contents of this level."

So, you can directly open or close the outline to _any_ desired level "N"
with C-N S-TAB. I find that feature to be incredibly handy. It encourages
me to nest my outlines as deeply as I wish.

Here's a little navigation utility I wrote to take advantage of S-TAB's
ability. Sometimes I'll want to collapse the outline to the level at point
in order, say, to clean things up by closing all lower levels. However,
it's not always obvious to me what level I'm on. And without knowing what
level I'm on, I can't hit the right numeric prefix for S-TAB. The following
utility does it all automagically by passing the result of
org-outline-level() to S-TAB. C-S-TAB is a logical binding for this
function.

(defun open-org-outline-to-current-level ()
  "Opens or closes the Orgmode outline to the level at point."
   (interactive)
   (org-shifttab (org-outline-level))
   (message "The current outline level is %s." (org-outline-level)))

Regards,
Tom Davey



On Thu, Aug 8, 2013 at 9:02 AM, Oleh  wrote:

> On Thu, Aug 8, 2013 at 9:01 AM, Carsten Dominik
>  wrote:
> >
> > On 23.7.2013, at 15:48, Oleh  wrote:
> >
> >> Hi all,
> >>
> >> I've recently started using `org-use-speed-commands', and I like it a
> lot,
> >> except I had to make one tweak:
> >>
> >>(setq org-use-speed-commands t)
> >>(setq org-speed-commands-user
> >>  '(("1" . (org-shifttab 1))
> >>("2" . (org-shifttab 2))
> >>("3" . (org-shifttab 3
> >>
> >> The corresponding values of `org-speed-commands-default' aren't that
> useful
> >> for GTD:
> >>
> >>("1" org-priority 65)
> >>("2" org-priority 66)
> >>("3" org-priority 67)
> >
> > That depends on wether you work with priorities.  I find S-TAB easy
> enough, so I do not
> > really see the need for speed commands here.
>
> Maybe I should elaborate my point of view on the usability.
> Priorities don't normally need "buttons" to jump between states,
> a "knob" is enough: only increase/decrease priority, not jump to priority
> 1,
> jump to priority 2 etc.
>
> Outlines, on the other hand, can benefit from the ability to jump between
> the levels of expansion.
>
> Level 1 is very useful - it minimizes everything, showing the
> structure of the file. S-TAB is useful and simple, but you have to
> repeat several times,
> checking each time if it has brought you to the level that you wanted to
> be on.
>
> Level 2 is very useful - and cannot, unlike Level 1, be reached by S-TAB.
> For my gtd.org, it shows the tasks and appointments, without expanding
> them, as well as the project names, but not what they contain.
> This gives a nice overview of my projects.
>
> Level 3 is very useful - and cannot be reached by S-TAB.
> It shows me the separate TODOs for my projects, without revealing my
> notes on them, just the headings.
> I even bound the rest of the digits to levels and it is useful sometimes.
>
> In my opinion, these shortcuts make org-mode a better outlining tool,
> and should be given priority before the priority shortcuts.
>
> Slightly off-topic, these type of shortcuts is why I use Ubuntu Unity (I
> think
> I managed to turn off the spying). It's got a feature that Super+1-9
> switches between applications in the sidebar slots 1-9. Sure, it's
> possible to do with Alt-TAB, and that's what most other desktops do,
> but Super+1-9 is superior, since you don't have to wait for feedback,
> you instantly get what you want.
>
> regards,
> Oleh
>
>


-- 
--
Tom Davey
t...@tomdavey.com
New York NY USA

Re: [O] bug#14605: Problem with export an .org file to .pdf does not open pdf file

[Suvayu Ali]

Hi Achim, Carsten,

On Mon, Sep 02, 2013 at 10:54:13PM +0200, Carsten Dominik wrote:
> 
> On 2.9.2013, at 18:54, Achim Gratz  wrote:
> 
> > Carsten Dominik writes:
> >> OK, we now use xdg-open when available on a Linux system.
> > 
> > The availability of xdg-open has nothing to do with whether or not you
> > are running Emacs on a Linux system.  Indeed, even on a system where it
> > is available, it won't do anything useful if you're running from a
> > console.  While I think it's a good default for someone using a desktop
> > that conforms to XDG standards, there should be a check if in fact Emacs
> > is running on such a desktop.
> 
> thanks for this input.  THis makes it more complicated.  Do you know
> how I would test this?  I do know about the variable window-system,
> but that will also return nil when Emacs is running in an xterm, even
> though xdg-open would be working in this case.

I think there are four cases of running from a console,

1. a true terminal (the one you get with Ctrl+Alt-Fn, or in runlevel 3)
2. a remote console without X forwarding
3. a remote console with X forwarding
4. a virtual terminal (terminal emulator in a graphical desktop)

Now xdg-open will not work for (1-2) (for different reasons), but will
work for (3-4).  I think it is reasonable to expect if someone chooses
"export and open", they are on a graphical desktop and not on (1-2).  As
for (3), I think even in that case most people will choose to just
export, and open in some other way (none of us like X forwarding do we?
;)).

As for desktop conformance, Gnome, KDE, XFCE (and by induction LXDE)
conforms.  I think the key is what happens when it does not: xdg-open
fallsback to its own settings.  Quoting the Archlinux wiki summary:

  Inside a desktop environment (e.g. GNOME, KDE, Xfce, etc.), xdg-open
  simply passes the arguments to that desktop environment's file-opener
  application (gvfs-open, kde-open, or exo-open, respectively), which
  means that the associations are left up to the desktop
  environment. When no desktop environment is detected (for example when
  one runs a standalone window manager, e.g. Openbox), xdg-open will use
  its own configuration files.
  ^^^

Given this fallback, I don't think there is much to worry about.  If it
is there, and the user is on a graphical desktop (3-4), it will work.
If it is absent, we still have mailcap.  Nothing to lose here.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] org-speed-commands-default 1 2 3

[Rainer Stengele]

Am 03.09.2013 00:35, schrieb Tom Davey:
> Olen writes:
> 
>> Level 2 is very useful - and cannot, unlike Level 1, be reached by S-TAB.
> 
> Actually, it can. S-TAB takes a numeric prefix key. The doc string says:
> 
> "When ARG is a numeric prefix, show contents of this level."
> 
> So, you can directly open or close the outline to _any_ desired level "N" 
> with C-N S-TAB. I find that feature to be incredibly handy. It encourages me 
> to nest my outlines as deeply
> as I wish.
> 
> Here's a little navigation utility I wrote to take advantage of S-TAB's 
> ability. Sometimes I'll want to collapse the outline to the level at point in 
> order, say, to clean things up
> by closing all lower levels. However, it's not always obvious to me what 
> level I'm on. And without knowing what level I'm on, I can't hit the right 
> numeric prefix for S-TAB. The
> following utility does it all automagically by passing the result of 
> org-outline-level() to S-TAB. C-S-TAB is a logical binding for this function.
> 
> (defun open-org-outline-to-current-level ()
>   "Opens or closes the Orgmode outline to the level at point."
>(interactive)
>(org-shifttab (org-outline-level))
>(message "The current outline level is %s." (org-outline-level)))
> 
> Regards,
> Tom Davey
> 
> 
> 
> On Thu, Aug 8, 2013 at 9:02 AM, Oleh  > wrote:
> 
> On Thu, Aug 8, 2013 at 9:01 AM, Carsten Dominik
> mailto:carsten.domi...@gmail.com>> wrote:
> >
> > On 23.7.2013, at 15:48, Oleh  > wrote:
> >
> >> Hi all,
> >>
> >> I've recently started using `org-use-speed-commands', and I like it a 
> lot,
> >> except I had to make one tweak:
> >>
> >>(setq org-use-speed-commands t)
> >>(setq org-speed-commands-user
> >>  '(("1" . (org-shifttab 1))
> >>("2" . (org-shifttab 2))
> >>("3" . (org-shifttab 3
> >>
> >> The corresponding values of `org-speed-commands-default' aren't that 
> useful
> >> for GTD:
> >>
> >>("1" org-priority 65)
> >>("2" org-priority 66)
> >>("3" org-priority 67)
> >
> > That depends on wether you work with priorities.  I find S-TAB easy 
> enough, so I do not
> > really see the need for speed commands here.
> 
> Maybe I should elaborate my point of view on the usability.
> Priorities don't normally need "buttons" to jump between states,
> a "knob" is enough: only increase/decrease priority, not jump to priority 
> 1,
> jump to priority 2 etc.
> 
> Outlines, on the other hand, can benefit from the ability to jump between
> the levels of expansion.
> 
> Level 1 is very useful - it minimizes everything, showing the
> structure of the file. S-TAB is useful and simple, but you have to
> repeat several times,
> checking each time if it has brought you to the level that you wanted to 
> be on.
> 
> Level 2 is very useful - and cannot, unlike Level 1, be reached by S-TAB.
> For my gtd.org , it shows the tasks and appointments, 
> without expanding
> them, as well as the project names, but not what they contain.
> This gives a nice overview of my projects.
> 
> Level 3 is very useful - and cannot be reached by S-TAB.
> It shows me the separate TODOs for my projects, without revealing my
> notes on them, just the headings.
> I even bound the rest of the digits to levels and it is useful sometimes.
> 
> In my opinion, these shortcuts make org-mode a better outlining tool,
> and should be given priority before the priority shortcuts.
> 
> Slightly off-topic, these type of shortcuts is why I use Ubuntu Unity (I 
> think
> I managed to turn off the spying). It's got a feature that Super+1-9
> switches between applications in the sidebar slots 1-9. Sure, it's
> possible to do with Alt-TAB, and that's what most other desktops do,
> but Super+1-9 is superior, since you don't have to wait for feedback,
> you instantly get what you want.
> 
> regards,
> Oleh
> 
> 
> 
> 
> -- 
> --
> Tom Davey
> t...@tomdavey.com 
> New York NY USA

"collapse the outline to the level at point" seems helpful to me!
Using "0" as speed key I end up with:

;; Outline level durch speedcommand setzen
;; "0": collapse the outline to the level at point
(setq org-use-speed-commands t)
(setq org-speed-commands-user
  '(("0" . (org-shifttab (org-outline-level)))
("1" . (org-shifttab 1))
("2" . (org-shifttab 2))
("3" . (org-shifttab 3))
("4" . (org-shifttab 4))
("5" . (org-shifttab 5

Thanks!
Rainer