Re: [O] bug#32722: bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

[Jonathan Leech-Pepin]

Hello,

On Mon, Dec 3, 2018 at 5:28 AM Van L  wrote:

>  > As already pointed out by Nicolas Goaziou, org-mode also requires other
>  > external stuff
>
> A data point.
>
> Ditaa requires a JRE as mentioned at
>
>   http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ditaa.html
>
> The litigious terms are
>
>   ditaa version 0.9, Copyright (C) 2004--2009  Efstathios (Stathis) Sideris
>
> I didn’t find ditaa.jar in org-mode’s contrib/scripts as claimed.
>

I can't speak for why it is/isn't in the contrib/scripts directory, but if
you go to Github
for the most up to date version it is GPLv3
https://github.com/stathissideris/ditaa/blob/master/LICENSE

Regards,
Jon

Re: [O] very long table calc expressions ?

[Jonathan Leech-Pepin]

Hi Uwe,

On Fri, Jun 22, 2018 at 10:16 AM, Uwe Brauer  wrote:

>
>> Uwe Brauer  writes:
>
>> When I hit C-c ' in this table
>
>> #+TBLNAME: stat-final2
>> || Frequency |
>
>> |+---|
>> | SS |   |
>> | AP | 5 |
>> | NT | 3 |
>> | SB |#ERROR |
>> | MH | 2 |
>> | NP | 3 |
>
>
>> I get a new window with this in it:
>
>> # Field and Range Formulas
>> @>$2 = '(length (org-lookup-all "NP" '(remote(data,@2$2..@>I$2))
> nil))
>> nil))
>> nil))
>> nil))
>
>> and I can edit individual lines and then C-c C-c or C-c ' again to
> exit
>> and rebuild the formula line on the table.
>
>
> Not for me, that is strange. Here is the screenshot I obtain (running
> git master emacs from May and org git master form last July, so maybe
> this feature is missing?)
>
> Pretty sure the spacer between formulas is supposed to be a double colon
(::)
not just a single.  Brent's example has it with double while yours only
shows
it with a single one.

Regards,
Jon

Re: [O] emacs , windows, gpg, org-crypt

[Jonathan Leech-Pepin]

On 29 March 2018 at 09:59, hymie!  wrote:

> Greetings.
>
> I set this all up years ago, I just got a new computer, I'm not an expert
> with Windows, and I've been unable to find my problem with Google.
>
> I have Windows 10, I have emacs, I have Org 9.0.3 (yes, I need to update),
> and I have GPG4Win.  I have entries in my .emacs file:
>
>  (require 'org-crypt)
>  (org-crypt-use-before-save-magic)
>  (setq org-tags-exclude-from-inheritance (quote ("crypt")))
>  [...]
>  (setq org-crypt-key "")
>;; GPG key to use for encryption
>  [...]
>  (global-set-key "\C-cd" 'org-decrypt-entry)
>  (global-set-key "\C-ce" 'org-encrypt-entry)
>
> But when I try to decrypt something, I get this error:
>
>   Searching for program: no such file or directory, gpg
>
> The only responses I can find are to add gpg to my %PATH% , but
> I don't think my employer's GPO will let me.


There is a machine/system %PATH% and a Current User %PATH%.
Normally GPOs will block you from modifying the system %PATH% but
allow you to change the User Path.  This may be an option.

I was hoping to find a place in org-crypt where "gpg" is defined so that
> I can specify a full path instead, but as yet, I haven't found it.


I'd take a look at ~C-h v -gpg TAB~ -> possible suggestion is
epg-gpg-program which points to "gpg" by default.
~org-encrypt-string~ uses epg for encryption purposes so changing
that program path should fix the issue.

--
Jon


> Can somebody give me a push?
>
> --hymie! http://lactose.homelinux.net/~hymie
> hy...@lactose.homelinux.net
>
>
>

Re: [O] [RFC] Dog food, anyone?

[Jonathan Leech-Pepin]

Hello,

On December 19, 2017 6:11:21 PM EST, Nicolas Goaziou <m...@nicolasgoaziou.fr> 
wrote:
>Hello,
>
>Jonathan Leech-Pepin <jonathan.leechpe...@gmail.com> writes:
>
>> As Thomas mentioned I had originally written the exporter.  
>
>I know. You are credited as the author of ox-texinfo.el. Did I mention
>otherwise?
>

It had partially sounded like you were saying both the backend and the work on 
manual.org were his. Might just have been a misinterpretation though.

>> I'd done my best to get it to work with the majority of the org.texi
>> however there were certain features that did not seem to be present
>at
>> the time in Org (or at least no convenient method to simulate them
>> without macros).
>
>Just to prevent miscommunication, I wasn't criticizing your work when
>I wrote I had improved the back-end.
>

I didn’t take it as criticism, when I’d started working on it the new export 
engine was still in it’s infancy and a lot of the work you’ve done to improve 
performance and parsing hadn’t occurred yet.  I’m glad it was complete enough 
to let Thomas start his work and give you a basis for improving to allow for a 
full manual.

>Regards,

-- 
Jonathan

Re: [O] [RFC] Dog food, anyone?

[Jonathan Leech-Pepin]

Hello Nicolas

On 17 December 2017 at 05:34, Nicolas Goaziou 
wrote:

> Hello,
>
> The task started by Thomas S. Dye a couple years ago is now complete.
> The "manual.org" file in "contrib/" directory is an up-to-date,
> sometimes enhanced, version of the Org manual. Org can now eat its own
> dog food.
>
> During the process, I had to re-organize some parts of the manual (e.g.,
> "Working with source code" section, the concept index...) and improve
> the "texinfo" export back-end, which was not up to the task when Thomas
> started it.
>

As Thomas mentioned I had originally written the exporter.  I'd done my best
to get it to work with the majority of the org.texi however there were
certain
features that did not seem to be present at the time in Org  (or at least no
convenient method to simulate them without macros).

I haven't had the chance to keep up with the exporter or the export engine
in
general, however I'm glad that the manual now can be entirely written in
Org.
That was part of the motivation behind writing the exporter in the first
place.

Regards,

--
Jonathan

Re: [O] Gnuplot and Windows

[Jonathan Leech-Pepin]

On 18 April 2017 at 09:26, Eric S Fraga  wrote:

> On Tuesday, 18 Apr 2017 at 10:09, Bala Ramadurai wrote:
> > Thanks Eric for your reply.
> >
> > Yes, I installed gnuplot, gnuplot-mode and gnuplot.el. Still, I get
> > this error. I fooled around with changing the variable gnuplot-program
> > to windows notation of the PATH. I added gnuplot.exe to the $PATH
> > variable as well.
>

Bala,

Does `(executable-find "gnuplot")` return the path to the executable?  If
not it might not be properly set in Windows (and/or Emacs was not restarted
with the updated environment variables).


> > Still no luck
>
> Well, hopefully others can help.  I do not use MS Windows and no nothing
> about it.
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.5-444-g998576
>

Regards,
Jon

Re: [O] template for writing Emacs manuals in Org

[Jonathan Leech-Pepin]

Hi,

On May 18, 2016 5:21:06 AM EDT, Rasmus  wrote:
>Hi,
>
>Nick Dokos  writes:
>
>> I believe the main obstacle is that the emacs policy requires a
>texinfo
>> manual for all its component parts.
>
>What is the "component parts"?  I couldn't find the definition.
>
>>  If that can be generated automatically from the org document, then
>any
>> objections probably disappear. Of course, Bastien might object to the
>> extra effort required to do the conversion, but if the conversion is
>> indeed completely automatic (or, perhaps more likely, a volunteer can
>be
>> found to take care of the conversion and any problems that might
>arise),
>> then he might be amenable to it. But it would be an extra step
>required
>> at release time and would require some coordination.
>
>My issue is all the damn macros.  While it displays the flexibility of
>Org, it also makes Org-for-texinfo-manuals less appealing.  I don’t
>want
>to learn new mini documentation language for each manual I might send
>patches to.
>
>Maybe a "Library-of-Macros" would go some of the way of at least making
>it
>feel less ad-hoc?
>
>Another annoyance.  When I see something like the an index right after
>a
>headline, I really would like to put the index into the properties
>drawer:
>
> ** Installation
>:PROPERTIES:
>:DESCRIPTION: How to install a downloaded version of Org-mode
>:END:
>
> {{{cindex(installation)}}}
>

I’m trying to remember why I didn’t implement indexes as properties (it may 
well have been because I simply didn’t consider it).  Assuming there’s nothing 
in the exporter to prevent converting properties to text after headlines it 
could work. Treat comma separated values as separate entries.

Then using the macro would only be needed if indexing at content rather than at 
a headline (use lower level headlines that do not become nodes and it could 
still work).

>Aside: I’ve been wanting a drawer property for inserting text just
>before
>headings (and maybe just after headings) for a while, e.g.
>
> EXPORT_BACKEND_{BEFORE, AFTER}, or
> INSERT_{BEFORE, AFTER}
>
>It would also be useful for latex, e.g.
>
>* Proofs
>  :PROPERTIES:
>  :EXPORT_LATEX_BEFORE: \appendix
>  :INSERT_BEFORE: @@latex:\appendix@@
>  :END:
>
>Rasmus

--
Jon

Re: [O] bug in org-habits

[Jonathan Leech-Pepin]

On November 3, 2015 4:31:11 PM EST, Achim Gratz  wrote:
>John Wiegley writes:
>> Thanks for discussing this with me, Nicolas. I appreciate there may
>be
>> technical complexities involved. Could we special-case allow
>PROPERTIES to be
>> the *very last thing* in an entry? I don't need it to float anywhere
>else. I
>> just like it to be at the end.
>
>Well, that's precisely the thing that doesn't scale and that Nicolas
>wanted to avoid.  Putting the properties at the beginning of an entry
>makes the search pretty much constant time and if you find something
>else at the start of the entry then you know there aren't any and can
>go
>on (this is pretty important for making sure property inheritance works
>correctly, among other things).  If you could put them _anywhere_ else,
>you'd have to keep searching until you either find them or you've
>exhausted the span of the entry.

Wouldn't last item in entry scale without issues? Find end of headline (start 
of next or end of buffer) and search backwards. If first element from end is a 
property drawer you have it, otherwise you still know there is none.

Jon

>
>Regards,
>Achim.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [O] The Org Manual

[Jonathan Leech-Pepin]

Hello,

On 24 September 2015 at 18:01, Rasmus  wrote:

> nascii boy  writes:
>
> > Org advancement manual in org
> >
> > https://github.com/nasciiboy/TheOrgManual
>
> Interesting.  Is this a port of the current org manual?  Does it produce
> good texi code with ox-texi?
>

Looking at it it looks as though it is an exact recreation of the
existing manual (did not verify version).

It includes all the texi-like section menus as manually created
targets.  This will not end up producing the expected out put in
ox-texinfo because those menu entries are dynamically generated in a
TOC-esque manner.  I did not look through to see if the various
indices and other texi-specific features were accounted for or just
hard coded in.

Regards,
Jon


> Thanks,
> Rasmus
>
> --
> Er du tosset for noge' lårt!
>
>
>

Re: [O] Capture-like browser plugin?

[Jonathan Leech-Pepin]

Hello Peter,

On 23 July 2015 at 10:18, Peter Davis p...@pfdstudio.com wrote:


 Frequently when I'm doing a Web search and find pages I like, I want to
 save a link to the page, along with the title and perhaps a
 few notes. Something like org-mode's capture would be great, but I'd like
 to initiate it from a browser. I imaging hitting a plugin
 button on the the browser's toolbar to open emacs via emacsclient, and
 essentially do a capture with the link and whatever text I
 care to enter.

 Has anyone seen or heard of or written something like this?


You want to take a look at [[org-protocol][
http://orgmode.org/worg/org-contrib/org-protocol.html]].  It can do more or
less exactly
what you're describing (with even additional options/features depending on
how you configure the template and the browser-side options.

Regards,
Jon


 Thanks!
 -pd

Re: [O] searching for csv utilities

[Jonathan Leech-Pepin]

On 3 June 2015 at 12:07, Jude DaShiell jdash...@panix.com wrote:

 This is a piece of a modified ecm that may show what's going on.

 cut here.
 |--+-+++|
 | Averages:| ||||
 | Counts:  | ||||
 | Maximums:| ||||
 | Medians: | ||||
 | Minimums:| ||||
 | Modes:   | ||||
 | Standard Deviations: | ||||
 | Sums:| 108.69) | 70.45) | 66.62) | 92.93) |
 |--+-+++|
 #+TBLFM: @$2..@$=vmean(@I..@;%.2f)

 I haven't even attempted the rest of the math since I have no way to
 predict where any of the results will land.


@ means last line, @ is second to last, @ third to last and so on.
So for 7th from the bottom it would be @.

Re: PrintF specification
Everything after the =;= is considered part of the specification, so the
=)= used to close the vmean is actually part of the specification.
Changing that to =vmean();%.2f= will correct it.



For your sample ECM (plus original data and one sample line to actually
confirm median works) you would work with the following (Apologies for the
very long TBLFM line):

I was unable to find a built-in to determine the mode.  I've found sample
functions on Stack Overflow that would calculate it based on a list, but
I'm not familiar enough with Org-Table format on how to go from cell
references =@I..@II= to a list of values for the sake of manipulating them.

: | Date |Sys |Dia |Pul |  Sugar |
: |--++++|
: | [2014-04-27 Sun] |125 | 88 | 78 | 92 |
: | [2014-04-28 Mon] |102 | 88 | 86 | 92 |
: | [2014-04-29 Tue] |115 | 88 | 85 | 95 |
: |--++++|
: | Averages:| 114.00 |  88.00 |  83.00 |  93.00 |
: | Counts:  |   3.00 |   3.00 |   3.00 |   3.00 |
: | Maximums:| 125.00 |  88.00 |  86.00 |  95.00 |
: | Medians: | 115.00 |  88.00 |  85.00 |  92.00 |
: | Minimums:| 102.00 |  88.00 |  78.00 |  92.00 |
: | Modes:   |||||
: | Standard Deviations: |  11.53 |   0.00 |   4.36 |   1.73 |
: | Sums:| 342.00 | 264.00 | 249.00 | 279.00 |
: |--++++|
: #+TBLFM: @$2..@$=vsum(@I..@II);%.2f::@$2..@$=vsdev(@I..@II
);%.2f::@$2..@$=vmin(@I..@II);%.2f::@$2..@
$=vmedian(@I..@II);%.2f::@$2..@$=vmax(@I..@II);%.2f::@
$2..@$=vcount(@I..@II);%.2f::@$2..@
$=vmean(@I..@II);%.2f

Regards,
Jonathan

On Tue, 2 Jun 2015, Jonathan Leech-Pepin wrote:

  Date: Tue, 2 Jun 2015 08:04:20
 From: Jonathan Leech-Pepin jonathan.leechpe...@gmail.com
 To: Jude DaShiell jdash...@panix.com
 Cc: Org Mode Mailing List emacs-orgmode@gnu.org
 Subject: Re: [O] searching for csv utilities

 Hello,

 On 2 June 2015 at 07:44, Jude DaShiell jdash...@panix.com wrote:

  | Date |   Sys | Dia | Pul | Sugar |
 |--+---+-+-+---|
 | [2014-04-27 Sun] |   125 |  88 |  78 |92 |
 | [2014-04-28 Mon] |   102 |  88 |  86 |92 |
 | Averages:| =$2=vmean(@..@) | | |   |
 #+TBLFM: $2=$2=vmean(@..@)


 The formula in question is the culprit in this case (at least as stated
 there).

 : $2=$2=vmean(@..@)

 Second column is equal to the second column which is equal to the mean of
 all the values in the second column (including the header Sys).

 If you change the table as follows:

 | Date |   Sys | Dia | Pul | Sugar |
 |--+---+-+-+---|
 | [2014-04-27 Sun] |   125 |  88 |  78 |92 |
 | [2014-04-28 Mon] |   102 |  88 |  86 |92 |
 |--+---+-+-+---|
 | Averages:| 113.5 |  88 |  82 |92 |
 #+TBLFM: @$2..@$=vmean(@I..@II)

 All the values will properly compute.  If you want to avoid the second
 HLINE above Averages: then change =@II= to =@= (penultimate row)

 Regards,
 Jon


  This is a cut down version of my full record set.  Sometimes when I key
 formulas in I get ?ERROR back for a result after keying in c-c+c-c once
 I've completed the formula and hit tab.  If I do c-u+c-c+c-c that
 sometimes
 generated ?ERROR.  Other times I key in a formula and the cursor gets
 locked and I have to hit c-g to exit #+TBLFM: mode; I don't know what's
 actually happening when that situation arises since other than suddenly
 finding the cursor locked I can neither tell what state I'm in or if a
 few
 more keystrokes are needed or if I've generated an error situation.

  --





 --

Re: [O] searching for csv utilities

[Jonathan Leech-Pepin]

Hello,

On 2 June 2015 at 07:44, Jude DaShiell jdash...@panix.com wrote:

 | Date |   Sys | Dia | Pul | Sugar |
 |--+---+-+-+---|
 | [2014-04-27 Sun] |   125 |  88 |  78 |92 |
 | [2014-04-28 Mon] |   102 |  88 |  86 |92 |
 | Averages:| =$2=vmean(@..@) | | |   |
 #+TBLFM: $2=$2=vmean(@..@)


The formula in question is the culprit in this case (at least as stated
there).

: $2=$2=vmean(@..@)

Second column is equal to the second column which is equal to the mean of
all the values in the second column (including the header Sys).

If you change the table as follows:

| Date |   Sys | Dia | Pul | Sugar |
|--+---+-+-+---|
| [2014-04-27 Sun] |   125 |  88 |  78 |92 |
| [2014-04-28 Mon] |   102 |  88 |  86 |92 |
|--+---+-+-+---|
| Averages:| 113.5 |  88 |  82 |92 |
#+TBLFM: @$2..@$=vmean(@I..@II)

All the values will properly compute.  If you want to avoid the second
HLINE above Averages: then change =@II= to =@= (penultimate row)

Regards,
Jon


 This is a cut down version of my full record set.  Sometimes when I key
 formulas in I get ?ERROR back for a result after keying in c-c+c-c once
 I've completed the formula and hit tab.  If I do c-u+c-c+c-c that sometimes
 generated ?ERROR.  Other times I key in a formula and the cursor gets
 locked and I have to hit c-g to exit #+TBLFM: mode; I don't know what's
 actually happening when that situation arises since other than suddenly
 finding the cursor locked I can neither tell what state I'm in or if a few
 more keystrokes are needed or if I've generated an error situation.

  --

[O] Programatic validation of code blocks for subsequent execution without prompting

[Jonathan Leech-Pepin]

Hello all,

I just wanted to share a bit of code I worked up for an
emacs.stackexchange.com question regarding evaluation code blocks without
confirmation if the code has not changed (useful when exporting multiple
times or using in call_src where you will not have a #+RESULT block to
cache results with.

The question and answer can be found here:
http://emacs.stackexchange.com/questions/499/finding-and-executing-org-babel-snippets-programatically/510#510

The code in question:

(defvar my/babel-hashes 'nil)
(defun my/babel-hashed-confirm (lang body)
  (let ((check (list lang (md5 body
;; If not hashed, prompt
(if (not (member (list lang (md5 body)) my/babel-hashes))
;; Ask if you want to hash
(if (yes-or-no-p Store hash for block? )
;; Hash is added, proceed with evaluation
(progn
  (add-to-list 'my/babel-hashes check)
  'nil)
  ;; Return 't to prompt for evaluation
  't

(setq org-confirm-babel-evaluate 'my/babel-hashed-confirm)



This allows for re-evaluation of the same code block (regardless of call
location or variables used) without subsequent prompting as long as the
body of the code block has not changed.  This will prevent accidental
insertions, or unintended changes from being evaluated without prompting,
while allowing re-evaluation as needed (For example an sql query that will
have different results over time).

Regards,
Jon

[O] org-element-at-point keep-trail?

[Jonathan Leech-Pepin]

Previously, org-element-at-point had an optional keep-trail variable that
was supposed to show the siblings, parents, aunts/uncles, grandparents, etc.

This feature no longer seems to be present.

What would the process be now to obtain the parents of a given element?

This would be useful for walking back up the tree to obtain a sparse-tree
structure for archiving (see:
http://lists.gnu.org/archive/html/emacs-orgmode/2014-10/msg00228.html)

Regards,
Jonathan

Re: [O] how to replace 'org-drawers'

[Jonathan Leech-Pepin]

Hello Alan

On 6 October 2014 08:23, Alan Schmitt alan.schm...@polytechnique.org
wrote:

 Hello,

 I'm trying to use org-wc, but it fails because org-drawers no longer
 exists. Is there a suggestion to change
 https://github.com/dato/org-wc/blob/master/org-wc.el#L55 such that it
 works with current org?


A quick search for variables reveals `org-drawer-regexp` [ ^[
]*:\\(\\(?:\\w\\|[-_]\\)+\\):[ ]*$ ]

It matches both the name of the drawer and `:END:`.

So the function could be adapted to use `org-drawer-regexp` instead
(untested but should match to the next :END:):

((looking-at org-drawer-regexp)
 (while (or (eobp)
(not (looking-at :END:)))
   (re-search-forward org-drawer-regexp nil t)))

Regards,
Jonathan


 Thanks,

 Alan

 --
 OpenPGP Key ID : 040D0A3B4ED2E5C7

Re: [O] How to utilize the vc package inside of the edit source block buffer?

[Jonathan Leech-Pepin]

Hello,

On 23 September 2014 14:19, Aaron Ecay aarone...@gmail.com wrote:

 Hi Grant,

 2014ko irailak 23an, Grant Rettke-ek idatzi zuen:
 
  Good afternoon,
 
  The ability to org-edit-special inside of source block is truly
 priceless.
 
  There is a delightful workflow to be found with approach.
 
  It has got me spending more and more time in the edit buffer though,
  wanting to utilize
  vc-next-action to initiate a commit. This is not possible because the
  buffer is not associated
  with a file.
 
  Is there some way to get tell Emacs to execute the action on the
  source buffer from which the
  source edit block buffer originated?

 One approach might be to advise the vc commands like (pseudocode):

 (defadvice vc-foo (around org-src activate)
   (when (in-src-edit-p)
 (org-edit-src-exit))
   ad-do-it)


The following would work as a wrapper:

(defun test-buffer ()
  (interactive)
  (when org-edit-src-from-org-mode
(let ((buffer (marker-buffer org-edit-src-beg-marker)))
  (with-current-buffer buffer
(message %s is current for file: %s
 (current-buffer)
 (buffer-file-name))

Replace (message ...) with `vc-next-action` or use the above as advice
[adjusting from (when..) to (if..)].

Regards,
Jonathan


 --
 Aaron Ecay

[O] [PATCH] org-passwords.el: Do not insert `org-passwords-generate-password-with-symbols`

[Jonathan Leech-Pepin]

Patch attached and inlined (to ensure gmail does not mangle)

Regards,
Jonathan



org-passwords.el: Fix `org-passwords-generate-password-with-symbols` to not
insert password

* org-passwords.el (org-passwords-generate-password-with-symbols): Do not
insert password,
this matches how `org-passwords-generate-password-without-symbols` behaves.
---
 contrib/lisp/org-passwords.el |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-passwords.el b/contrib/lisp/org-passwords.el
index 7ed8c80..9c3a916 100644
--- a/contrib/lisp/org-passwords.el
+++ b/contrib/lisp/org-passwords.el
@@ -221,12 +221,12 @@ uppercase letters.  Argument ARG include symbols.
   Return a string consisting of PREVIOUS-STRING and
 NUMS-OF-CHARS random characters.
   (if (eq nums-of-chars 0) previous-string
-(insert (org-passwords-generate-password-with-symbols
+(org-passwords-generate-password-with-symbols
  (concat previous-string
  (char-to-string
   ;; symbols, letters, numbers are from 33 to 126
   (+ (random (- 127 33)) 33)))
- (1- nums-of-chars)
+ (1- nums-of-chars

 (defun org-passwords-generate-password-without-symbols (previous-string
nums-of-chars)
   Return string consisting of PREVIOUS-STRING and NUMS-OF-CHARS
-- 
1.7.9


0001-org-passwords.el-Fix-org-passwords-generate-password.patch
Description: Binary data

[O] [PATCH] ob-sql.el: Add support for MS sqlcmd

[Jonathan Leech-Pepin]

Patch provided inline and as attachment to ensure gmail does not mangle it.

Regards,
Jonathan



ob-sql.el: Add support for sqlcmd

* lisp/ob-sql.el (org-babel-execute:sql): Add support for sqlcmd on
  Windows.  This is a replacement for osql.
---
 lisp/ob-sql.el |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 7b85df8..e96d55d 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -116,6 +116,12 @@ This function is called by
`org-babel-execute-src-block'.
  (or cmdline )
  (org-babel-process-file-name in-file)
  (org-babel-process-file-name
out-file)))
+('mssqlcmd (format sqlcmd %s -S %s -s \\t\ -i %s -o %s
+(or cmdline )
+dbhost
+(org-babel-process-file-name in-file)
+(org-babel-process-file-name
+ out-file)))
 ('mysql (format mysql %s %s %s  %s  %s
 (dbstring-mysql dbhost dbuser dbpassword database)
 (if colnames-p  -N)
-- 
1.7.9


0001-ob-sql.el-Add-support-for-sqlcmd.patch
Description: Binary data

Re: [O] Moving my init.el to Org

[Jonathan Leech-Pepin]

Hello,

On 2 September 2014 08:42, Rasmus ras...@gmx.us wrote:

 Rainer M Krug rai...@krugs.de writes:

  Oleh ohwoeo...@gmail.com writes:
 
  I know that I could use org-babel-load-file, or outshine.  What are
  other possibilities?  What are the caveats (and advantages) of both
  (other?) ways?
 
  I'm using a one .el file per mode approach, with around 4000 lines
  split into 40 files.
 
  This approach simplifies things a lot: for instance I haven't touched
  Javascript in ages, but all my customizations for it are sitting in
  javascript.el without getting in the way of the stuff that I'm using
  now. They aren't even loaded unless I open a js file.
 
  Interesting - is your configuration online, so that one could take a
  look at it? I did not find them on your github page?
 
  Or how do you do it, that the e.g. javascript.el is only loaded when a
  js file is opened? Because this is exactly what I would like to have.

 How about something like this:

 (with-eval-after-load 'js-mode (load javascript.el))

 Use eval-after-load if you are using an older Emacs.  Note I don't
 know if there's anything called js-mode. . .


I've been using use-package (https://github.com/jwiegley/use-package) for
only loading the various package-specific configurations when needed.

For that example it would be:

(use-package js-mode
  :mode (\\.js\\' . js-mode)
  :config (require 'javascript) ;; or (load javascript.el) if not provided
)

In my case it's still all in my init.el (with Outshine headings for each
mode that use-package manages), but could easily extract the portions into
their own files (especially for larger configurations like org)

Regards,
Jon

[O] Fwd: Re: How to identify all headings that won't be exported?

[Jonathan Leech-Pepin]

Forwarding to list. Somehow reply-all did not actually reply to all
-- Forwarded message --
From: Jonathan Leech-Pepin jonathan.leechpe...@gmail.com
Date: Jun 26, 2014 4:05 PM
Subject: Re: [O] How to identify all headings that won't be exported?
To: Thomas S. Dye t...@tsdye.com
Cc:

Hello Thomas


On 26 June 2014 15:09, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 Inspired by John Kitchin's org-ref, I'm working on a little function that
 returns all the pieces of an Org mode file that are candidates for cross
 referencing. The helm package lets me choose from among the candidates
 and then another little function inserts the chosen link.

 This all works for me, and I'm finding it really useful.  The only
 slight problem is that I haven't been able to figure out how to
 eliminate all the headings that won't be exported.  You'll see in the
 code below that my simple-minded approach gets all the headings tagged
 :noexport:, but it doesn't understand that the tag is inherited by
 descendants. Is there a practical way to identify descendants for my use
 case?

   (defun tsd-get-names-labels-and-headings ()
 (interactive)
 (save-excursion
   (goto-char (point-min))
   (let ((matches))
 (while
 (re-search-forward \\#\\+\\(name\\|label\\):\\s-\\(.*\\)
 (point-max) t)
   (add-to-list 'matches (match-string-no-properties 2) t))
 (dolist (heading (org-map-entries 'org-heading-components))
   (when (and (nth 4 heading) (not (search noexport(nth 5
 heading
 (add-to-list 'matches (nth 4 heading
 (dolist (properties (org-map-entries 'org-entry-properties))
   (when (cdr (assoc CUSTOM_ID properties))
 (add-to-list 'matches
  (format #%s (cdr (assoc CUSTOM_ID
 properties))
 (sort matches 'string


For the matching portion itself the following should work:

(org-map-entries (lambda () (org-element-property :raw-value
(org-element-at-point))) (format -%s (mapconcat 'identity
org-export-exclude-tags -)))

Rather than try and search for the tag afterwards, create a string that
will match all non-exporting tags and have them excluded from the match
itself (by default this will be -noexport but if you add test it will
become -noexport-test).  It also gives you the exact raw value of the
element.  Using just 'org-element-at-point would give you the entire
element, allowing you to display the :raw-value in your output but also
have the associated :begin to jump to, removing the need to search for the
headline again later on.




 All the best,
 Tom

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

Re: [O] Maintainer change on May 1st

[Jonathan Leech-Pepin]

On 8 April 2014 04:03, Glyn Millington glyn.milling...@gmail.com wrote:

 Rainer M Krug rai...@krugs.de writes:

  Carsten Dominik carsten.domi...@gmail.com writes:
 
  Hi everyone,
 
  per May 1st, I would like to swing the official maintainership back to
  Bastien, who has agreed to this change.  This really only means putting
  facts onto websites, because Bastien has in effect been doing this job
 all
  the time - I have unfortunately been unable to make time free to
 contribute
  here in any meaningful way, for which I apologise. I trust that an
  overwhelming majority of you will have not objections to this step
 
  To make this overwhelming majority not to silent, I have no objections
  at all.
 
  Thanks for all the hard work you and Bastien have put into org.

 Another big thank you from a not-so-silent user!

 atb


 Glyn


 Another thank you to both of you for your hard work.  And absolutely no
objections to the change.

Jon

Re: [O] org-element-context doesn't parse consistently link with spaces

[Jonathan Leech-Pepin]

Hello Nicolas

On 5 March 2014 09:25, Nicolas Goaziou n.goaz...@gmail.com wrote:

 Daimrod daim...@gmail.com writes:

  I had forgotten to rerun make after I pulled the latest version.
  `org-version' now returns 8.2.5h.

 This is still not right. 8.2.5h refers to maint branch, where cache
 doesn't exist.

 When I compile the latest release on master, I get:

   Org-mode version 8.2.5e (release_8.2.5e-231-g51718d)

 So, I'm confused. On what branch are you?


Output from eshell freshly pulling right now:

,--
| ~/build/org $ git
stat
| git: 'stat' is not a git command. See 'git
--help'.
|

| Did you mean one of
these?
|
status

|
stage

|
stash

| ~/build/org $ git
status
| On branch
master
| Your branch is up-to-date with
'origin/master'.
|

| nothing to commit, working directory
clean
| ~/build/org $ c:/cygwin/bin/make
autoloads
| /usr/bin/make -C lisp
autoloads
| make[1]: Entering directory
'/cygdrive/c/Users/jonpe/build/org/lisp'
| rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc
org-install.elc
| cygwin
warning:

|   MS-DOS style path detected:
c:/Users/jonpe/build/org
|   Preferred POSIX equivalent is:
/cygdrive/c/Users/jonpe/build/org
|   CYGWIN environment variable option nodosfilewarning turns off this
warning.
|   Consult the user's guide for more details about POSIX
paths:
| http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

| org-version: 8.2.5h
(release_8.2.5h-678-g51718d)
`--

I initially cloned Org onto this machine 1 week ago.  8.2.5h should be on
master as well according to the above


 Regards,

 --
 Nicolas Goaziou


Regards,
Jon

Re: [O] Parser - which values are possible for `archivedp'?

[Jonathan Leech-Pepin]

Hello,

On 4 March 2014 09:47, Thorsten Jolitz tjol...@gmail.com wrote:

 Nick Dokos ndo...@gmail.com writes:

  Thorsten Jolitz tjol...@gmail.com writes:
 
  Hi List,
 
  the name of headline attribute `archivedp' suggests its just a boolean
  nil/t variable, but in parse trees I see e.g. a list as value
 
  ,---
  | :archivedp (ARCHIVE)
  `---
 
  and I vaguely remember that I have seen different symbols as values of
  this attribute too.
 
  So what do I have to expect as values here? A list of strings or nil? Or
  something else too? Whatever is defined in
 
  ,---
  | org-archive-tag is a variable defined in `org.el'.
  | Its value is ARCHIVE
  `---
 
  ?
 
  PS
 
  If the tag is just a string like in this case, why is it shown as
  list in the parse tree?
 
  It is set like this
(let
 ...
 (archivedp (member org-archive-tag tags))
 ...)
 
  in org-element.el. It is effectively a boolean, but there is no
  need to reduce the return value of ``member'' to t if it is non-nil:
 
  ,
  |member is a built-in function in `C source code'.
  |
  | (member ELT LIST)
  |
  | Return non-nil if ELT is an element of LIST.  Comparison done with
  | equal'.
  `
 
  So if non-nil, it will be a list of tags, starting with the value of
  org-archive-tag. AFAICT, the rest of the tags can be arbitrary.


 ** Second Level 2 :tag:my:ARCHIVE:


 ,
 | :tags (tag my) [...] :archivedp (ARCHIVE)
 `


Change the order of the tags so that Archive comes before the others and
you get:

** Second level 2 :ARCHIVE:tag:my:
:tags (tag my) :archivedp (ARCHIVE tag my)

Regards,
Jon


 --
 cheers,
 Thorsten

Re: [O] encrypted items, but not timestamp

[Jonathan Leech-Pepin]

Hello,


On 3 March 2014 07:28, Bastien b...@gnu.org wrote:

 Hi David,

 David Belohrad da...@belohrad.ch writes:

  I have followed this:
 
  http://orgmode.org/worg/org-tutorials/encrypting-files.html
 
  to encrypt subtree of my journal. So e.g. something like this:
 
   testing subree encryption
 :crypt:
  this text should be encrypted when saved on the disk using my private
  key. will see if this works
  Entered on 2014-02-20 Thu 09:05
 
 
  it works, however it encrypts entire subtree including 'entered on
  timestamp'. This puts a little issue on this, as when in journal,
  these timestamps are used in agenda buffer to display the heading. And I
  want this heading to be displayed in my agenda, including all the tags
  it exhibits.
 
  Is there any way how to achieve this?

 Nope, sorry.


I can think of one possible method (although slightly more work to do so):

(written longhand so tags won't be properly aligned, sorry)

 Testing subtree encryption add tags here
Entered on 2014-02-20 Thu 09:05
* Encrypted entry   :crypt:
this text should be encrypted when saved on the disk using my private
key. will see if this works

This will result in the encrypted subtree being encrypted, the headline
with it's timestamp being visible.

Regards,
Jon

  For the moment the only thing
  coming into my mind is to make a timestamp part of heading, which is not
  what I really want.

 That's also the only workaround I can think of right now.

 Best,

 --
  Bastien

Re: [O] Change Todo colors

[Jonathan Leech-Pepin]

Should be able to just use `org-todo-keyword-faces` the way he was trying
in the original post.  I've got the following in my init.el.  Re-evaluating
it after changes (C-M-x) and then switching back to an org buffer makes the
changes on the fly:

,
| (setq
org-todo-keyword-faces
| `((TODO
|:weight bold
|:foreground ,(jlp/zenburn-color zenburn-cyan))
|   (CLOSE
|:weight bold
|:underline (:color
|,(jlp/zenburn-color
|  zenburn-blue))
|:foreground ,(jlp/zenburn-color
|  zenburn-red))
|   (WAIT
|:weight bold
|:foreground ,(jlp/zenburn-color
|  zenburn-yellow))
|   (PEND
|:weight bold
|:foreground ,(jlp/zenburn-color
|  zenburn-orange))
|   (MEET
|:weight bold
|:foreground ,(jlp/zenburn-color
|  zenburn-yellow))
|   (MET
|:weight bold
|:foreground ,(jlp/zenburn-color
|  zenburn-yellow-2))
|   (TIME
|:weight bold
|:foreground ,(jlp/zenburn-color
|  zenburn-yellow))
|   (CLOCKED
|:weight bold
|:foreground ,(jlp/zenburn-color
|zenburn-yellow-2
`

jlp/zenburn-color is just a shortcut to pull the list of colors from the
Zenburn color theme rather than have to remember the equivalent HEX colors.

Regards,
Jon


On 3 March 2014 10:11, Fabrice Niessen fni-n...@pirilampo.org wrote:

 zwz wrote:
  Chris Henderson henders...@gmail.com writes:
 
  I'd like to change the color of Next to Red and Started to brown. At the
  moment, todo/ next and started all showing as red.
 
  Here is my .emacs snippet.
 
  (setq org-todo-keywords
  '((sequence TODO(t) Next(n) Started(s) | DONE(d!))
(sequence | CANCELED(c
 
  (setq org-todo-keyword-faces
 '((CANCELED . (:foreground blue :weight bold
 
  You should use custom-set-faces instead of setq.

 or `set-face-attribute', as I do in my Emacs configuration file[1]:

 --8---cut here---start-8---
   (with-eval-after-load org-faces

 ;; faces for specific TODO keywords
 (setq org-todo-keyword-faces
   '((NEW  . leuven-org-created-kwd)
 (TODO . org-todo)
 (STRT . leuven-org-inprogress-kwd)
 (WAIT . leuven-org-waiting-for-kwd)
 (SDAY . leuven-org-someday-kwd)
 (DONE . org-done)
 (CANX . org-done)))

 ;; Org standard faces
 (set-face-attribute 'org-todo nil
 :weight 'bold :box '(:line-width 1 :color
 #D8ABA7)
 :foreground #D8ABA7 :background #FFE6E4)

 (set-face-attribute 'org-done nil
 :weight 'bold :box '(:line-width 1 :color
 #BB)
 :foreground #BB :background #F0F0F0)

 ;; Org non-standard faces
 (defface leuven-org-created-kwd
   '((t (:weight normal :box (:line-width 1 :color #EEE9C3)
 :foreground #1A1A1A :background #FDFCD8)))
   Face used to display state NEW.)
 (defface leuven-org-inprogress-kwd
   '((t (:weight bold :box (:line-width 1 :color #D9D14A)
 :foreground #D9D14A :background #FCFCDC)))
   Face used to display state STRT.)
 (defface leuven-org-waiting-for-kwd
   '((t (:weight bold :box (:line-width 1 :color #89C58F)
 :foreground #89C58F :background #E2FEDE)))
   Face used to display state WAIT.)
 (defface leuven-org-someday-kwd
   '((t (:weight bold :box (:line-width 1 :color #9EB6D4)
 :foreground #9EB6D4 :background #E0EFFF)))
   Face used to display state SDAY.))
 --8---cut here---end---8---

 Best regards,
 Fabrice

 [1] https://github.com/fniessen/emacs-leuven/blob/master/emacs-leuven.el

 --
 Fabrice Niessen
 Leuven, Belgium
 http://www.pirilampo.org/

Re: [O] Context of interaction vs. literal syntactic interpretation

[Jonathan Leech-Pepin]

Hello,

On 3 March 2014 11:09, Matt Lundin m...@imapmail.org wrote:

 Bastien b...@altern.org writes:
 
  For most commands, the first literal syntactic interpretation is the
  only relevant context of interaction: e.g., it would not make sense to
  try updating a tag outside of a headline (i.e. outside of where a tag
  is a tag, from the parser's view.)
 
  For some commands, another higher context can also be relevant: e.g.,
  when the point is on a heading and the user hit C-c C-o, Org needs to
  know whether we are on a link (in this case it will open the link).  If
  not, it checks for a higher context: when we are on a heading, it will
  look for multiple links and prompt the user for which one to open.
 
  (A generalization of this links-in-a-heading behavior for something
  like links-in-a-paragraph, as suggested by Gustav, is a good idea.)

 Is the question here perhaps a simple one of refactoring?

 Nicolas is doing amazing work at making org file parsing more
 systematic, precise, and predictable. (Thank you!) And I agree with him
 that a function named org-open-link-at-point should, for the sake of
 precision and consistency, only open a link at the point.

 I also agree that such a function should do nothing in the context of a
 comment, which should simply be a string. FWIW, it seems to me that
 there are still several places in the source code that could be cleaned
 up in this way. For instance, org-mode code examples designated for
 export have unwanted effects in the agenda. Try putting this in an
 agenda file...

 --8---cut here---start-8---
 * An example
 : * Watch me
 :  2014-03-03 Mon 9:00
 --8---cut here---end---8---

 The problem, it seems to me, is that org-open-at-point is ambiguously
 named. The last bit, at-point, suggests a precise scope, but the
 beginning org-open implies a broad, fuzzy scope (i.e., it is not clear
 what is being opened). The problem is that org-open-at-point doubles as
 a meta function and a more precise function to open links at the point
 --- i.e., it implements within itself all the internals this more
 precise task.

 Org, of course, has a lot of helpful dwim functions (e.g.,
 org-meta-return, org-cycle, etc.). I would not want to lose these. As
 Bastien suggested, these functions are precisely what make org-mode so
 easy and intuitive to use. However, org has historically implemented
 many of its internals in an ad-hoc fashion within very large functions.
 This has led to some redundancy and opacity. This is especially true for
 a function like org-open-at-point, which is both precise and broad. This
 is where org-mode stands a lot to gain from refactoring the code base
 around Nicolas's parser.

 My view is that precision and usability need not be mutually exclusive.
 Might we have a bunch of precise, modular functions that rely on the new
 parser? E.g., something like org-open-link-at-point. This would do
 exactly what it says -- i.e., open a link if one is at the point. Then,
 on top of these function s we could rebuild fuzzier meta and dwim
 functions (e.g., org-open-links-in-paragraph, org-open-links-in-entry,
 org-meta-open, org-open-at-point,... whatever).

 In short, I am excited by the potential that the parser provides to make
 the code base more transparent, granular, and precise.

 Matt


I have to agree with Nicolas' opion and Matt's take on how it could be
implemented.

Have org-open-at-point do exactly what it says, act on what is at
point (be it a link, a timestamp, a footnote definition, etc).

Then have C-c C-o be a one of the meta overloaded functions that finds
context and acts on it accordingly:

- If object at point can be opened, opened it
- If in a paragraph, find all actionable[1] items and offer them for
  selection
- If on a headline, find all actionable[1] items and offer them for
  selection

[1] Footnotes and links In my opinion you wouldn't want it to also
include timestamps (for paragraphs and headlines) and tags (for
headlines) because those are agenda commands rather than navigation
commands.

If I'm on a timestamp or tag, opening it makes sense.  If I'm trying
to open from a headline/paragraph, I'm likely looking for links (which
can include footnotes since they link to another portion of the
document) so wouldn't want agenda commands.  Or have it customizable
as a set of alists that map what should be collected at what level.
For example:

#+begin_src emacs-lisp
  (setq org-open-context '((point . 'org-open-at-point)
   (footnote . 'nil)
   (sourceblock . 'nil)
   (table . 'nil)
   (paragraph . 'org-open-collect-links)
   (headline . 'org-open-collect-links)))
#+end_src

If something of this sort is then implemented on all the various
overloaded commands (M-Ret, C-Ret, C-c C-c, etc) it should reduce at
least some of the 

Re: [O] Keyboard shortcut - is there a principle behind them?

[Jonathan Leech-Pepin]

Hello,

On 6 December 2013 05:01, Rainer M Krug rai...@krugs.de wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 12/06/13, 10:49 , Oleh wrote:
 Initially the shortcuts were mnemonic, e.g. C-e:
 `move-end-of-line'. Obviously the keys ran out pretty quick.

 I can really imagine. But this explains some - but following your
 example: C-a moves to the beginning of the line - the only a there
 is in Anfang, which is German for beginning. So only partial luck
 here.

I can't speak for the original developers however my take on this one
is as follows:

C-b (for beginning) is used for back
C-s (for start) is used for search, C-f (find) was forward.
C-a becomes beginning-of-line by virtue of being the beginning of the alphabet.

Regards,
Jonathan

 Now only few shortcuts are reserved for user space and plugins, the
 most notable of which is the `C-c` prefix. That's why most custom
 modes such as org-mode and ESS bind to shortcuts with `C-c` prefix:
 there's a convention that Emacs core will not use `C-c`.

 Ah - very good to know.


 A nice way of remembering shortcuts only when you need them is to
 call commands by name with `M-x`. After a while, when you note that
 you're using one particular command a lot, you'll want to learn the
 shortcut for it.

 That's how I do it - but it involves learning sequences which do not
 make any sense to me - and I am sure there is some sense in the
 sequence, at least within each mode.


 There's one package that might be of good use to you: `smex'. It
 uses ido completion for `M-x`. You can install it from
 MELPA/Marmelade. It binds automatically to `M-x` when you install,
 although I recommend: (global-set-key \C-t 'smex)

 Yes - smex and ido are *very* useful - I do not know how one can use
 emacs without them.


 As an example, say you want to tangle. Here's what you do: C-t
 tang Now you see a bunch of rectangle commands mixed into the
 bunch. You can filter them out by noting that tangle commands have
 `org` in their name. C-SPC org C-SPC Now there's only 7 candidates
 left and you can select the one you want with C-m either by cycling
 with C-s or continuing to type part of name.

 `smex` logs the commands you use most. For them it usually takes
 less than 2-3 characters from the name to be recognized. E.g. if
 you use `org-babel-tangle` a lot, you can usually call it with C-t
 bab C-m.

 Very true and very useful.


 Finally note that no shortcuts are set in stone. You can customize
 all of them if you want to do so. For instance, and probably a lot
 of people will disagree, it doesn't make sense for me to have
 `previous-line' on C-p. So I swap C-p and C-h: (keyboard-translate
 ?\C-h ?\C-p) (keyboard-translate ?\C-p ?\C-h)

 Absolutely true - but I usually try to keep the customization to a
 minimum and to use the defaults.

 Thanks,

 Rainer


 Oleh


 On Fri, Dec 6, 2013 at 10:02 AM, Rainer M Krug rai...@krugs.de
 wrote: Hi

 one alternative subject could be because it is Friday...

 I am using org-mode and ess regularly, and I use quite a few
 keyboard shortcuts, but each time I read about a new one, I am
 wondering: why the heck these specific (default!) keyboard
 shortcuts?

 I am not asking why keyboard sequence, but e.g. why export in org
 is C-c e and why tangle is C-c C-v t, and so on.

 In other words: I am trying to *understand* why C-c and not C-o,
 because I have tremendous problems to remember the shortcuts - if
 I would know that there is s tree structure, where each following
 key narrows it down to further *thematically linked* commands, it
 would make it easier to learn these.

 Any insight into this? Or is there a emacs function which returns
 a random keyboard shortcut for a given function (some emacs
 shortcuts really seem to be that way...).

 Thanks,

 Rainer




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

 Centre of Excellence for Invasion Biology
 Stellenbosch University
 South Africa

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

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

 email:  rai...@krugs.de

 Skype:  RMkrug
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJSoaB0AAoJENvXNx4PUvmColIIAIy4AQTri6yZ6wVh8hp3/5gV
 RnY8oAXfHTBGW136AwXe2H9fMwfuyc+UA6rqcGzKMx0L1SCdNBXpK3Tfn2gFjRph
 iP/0TEqZgTXIwJurmn33yG6h9a0ABmEXVky+jOkHouldhjt7uuUyvT0LqmYw9pPs
 NFQAU1zmVFgh/nEiJvP2VKilXPh+NXo6ulPjhtAIDb/KjGLTy0SkPJYAF6Do4WYY
 wgbh+GCDzEWKgM+zQfzTq1CydX9FUdWw/zdbULhfu+f+J3/dZWtAlMfSsPi8N38g
 tAVJA/ycKqIMX3/GPlN7FlscPIdYnHxvJRo45MP/3mxkiI5B5vTn9sG90/J1dwU=
 =p6dh
 -END PGP SIGNATURE-

[O] Bug: Symbol's function definition is void: vc-git-root

[Jonathan Leech-Pepin]

Hello,

Using 8.2.2 I get the following error when using any org-attach-* commands:

(From *Messages* buffer)

Select command: [acmlzoOfFdD]
org-attach-commit: Symbol's function definition is void: vc-git-root


I don't have git installed on this Windows machine, so vc-git is never loaded.

Regards,
Jon

Re: [O] org-grep, and problems

[Jonathan Leech-Pepin]

Hello,

On Oct 14, 2013 10:43 AM, James Harkins jamshar...@gmail.com wrote:

 R. Michael Weylandt michael.weylandt at gmail.com michael.weylandt
at
 gmail.com writes:

  On Oct 10, 2013, at 11:50, François Pinard pinard at iro.umontreal.ca

 wrote:
 
  
   P.S. What is proper English: nobody remember or nobody remembers?
  
 
  Remembers. 'Nobody' counts as singular, as does 'no one'. English isn't
 totally consistent on this
  matter, however, as 'none' takes a plural verb.
 
  No one is brave enough to skip the meeting, even though none of the
bosses
 are going to attend.

 Actually, I think the latter clause is incorrect usage. The verb's
subject is
 none, not bosses; since the subject is singular, the verb form should
be
 singular as well. It feels wrong to have a singular verb immediately
after a
 plural noun, but that noun properly belongs to the preposition, not the
verb.

 I'm voting for none of the bosses is going to attend.

None is a bit of an odd case, since it reflects the plurality of the
associated noun.

None of the group is going...
None of the groups are going...
None of the bosses are going to attend.

Some, most, all also follow that pattern:
All of the group is...
All of the bosses are...

Group allows for both the plural and similar case since even one group
still has multiple members (at least it implies such).

Jon

 hjh

Re: [O] [AGENDA VIEW] Isn't g supposed to refresh agenda views ?

[Jonathan Leech-Pepin]

Hello,

On Aug 14, 2013 10:32 AM, Nick Dokos ndo...@gmail.com wrote:

 Xavier Maillard xav...@maillard.im writes:

  Hello again,
 
  With my copy of orgmode, pressing g in the Agenda View does not behave
  as I would have expected it.
 
  Here is the docstring:
 
  g runs the command org-agenda-redo, which is an interactive compiled
  Lisp function in `org-agenda.el'.
 
  It is bound to g, menu-bar Agenda Rebuild buffer.
 
  (org-agenda-redo optional ALL)
 
  Rebuild possibly ALL agenda view(s) in the current buffer.
 
  Though it effectively does something, it does not really refresh my
  agenda view since, as of the date of today (Wednesday 14th), it is stuck
  to yesterday...
 

 I've never tried leaving an agenda buffer open overnight and refresh it
 in the morning: if I remember, I'll try it tonight and see what happens
 (I could simulate the whole thing right now but no time).


I  have, it maintains the old date as current for the agenda view.  I dint
see this as a problem however since the agenda can look at any arbitrary
date, not just today.  Changing the date to today by hitting . should
update the agenda view appropriately.

If you manually change the date by moving forward or backward, or by
changing the range from day to week to month it will refresh based on those
settings, but the ones used to create the agenda initially.

Regards,

Jonathan
  What can I do to debug this ?

 You should probably check the variables whose names start with
 ``org-agenda-start-...'' to make sure that they have not been
 inadvertently modified incorrectly, particularly
 org-agenda-start-on-weekday.

 What I would do is run edebug on org-agenda-redo and make sure it is
 executed, but assuming that it is, it sounds like it is making the
 implicit assumption that the agenda was created today. You can always
 quit the agenda buffer and recreate it: that should work.

 
  Additional informations:
  1. GNU emacs 24.3.1
  2. org-mode from Git (dunno how to give you its version though)
 

 M-x org-version RET

 --
 Nick

[O] Daily snapshot issue

[Jonathan Leech-Pepin]

Hello all,

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.

Is there an issue with the snapshot?

Regards,
Jonathan

Re: [O] Hotlist agenda view: how to simplify its expression?

[Jonathan Leech-Pepin]

Hello,

On Aug 9, 2013 10:57 AM, Sebastien Vauban sva-n...@mygooglest.com wrote:

 Hello,

 Suppose I want a convenient way to see my most important tasks, the ones
 which:

 - are due soon (in the next 7 days), or
 - have a high priority (#A), or
 - are FLAGGED.

 If I don't mind having the entries mixed, this is quite simple and short:

 #+begin_src emacs-lisp
   (add-to-list 'org-agenda-custom-commands
'(H Hotlist
  tags-todo DEADLINE=\+1w\|PRIORITY=\A\|FLAGGED
  ((org-agenda-todo-ignore-scheduled 'future))) t)
 #+end_src

 Though, if I want 3 different blocks (in the above order) with *no
repetition*
 of entries, I need to write such a monster expression:

 #+begin_src emacs-lisp
   (add-to-list 'org-agenda-custom-commands
'(I Hotlist
  ((tags-todo DEADLINE=\+1w\
  ((org-agenda-overriding-header Due in next
7 days)))
   (tags-todo
PRIORITY=\A\+DEADLINE=\\|PRIORITY=\A\+DEADLINE\+1w\
  ((org-agenda-overriding-header High
priority)))
   (tags-todo
FLAGGED+PRIORITY=\\+DEADLINE=\\|FLAGGED+PRIORITY=\\+DEADLINE\+1w\|FLAGGED+PRIORITY\A\+DEADLINE=\\|FLAGGED+PRIORITY\A\+DEADLINE\+1w\
  ((org-agenda-overriding-header Starred
  ((org-agenda-todo-ignore-scheduled 'future))) t)
 #+end_src

 Do you see a way to optimize it (make it shorter)?  On the problems
relies in
 the fact that the inverse of

 DEADLINE=+1w

 is

 DEADLINE=|DEADLINE+1w

 that is 2 tests to be done.

 The same applies for the priorities: the inverse of

 PRIORITY=\A\

 is

 PRIORITY=|PRIORITYA

 Hence, an exponential number of checks every time you want to remove
 duplicated entries (which would have been displayed in the previous
block):
 you double the number of subexpressions in the next block...

Could you use (org-agenda-skip-regexp ...) combined with
(org-agenda-skip-function (org-agenda-skip-entry-when-regexp-matches))

Just change the ... in the above to the deadline/priority you want to
exclude in the block.

Sorry if this is at all unclear, sending from my phone so hard to write out
the code blocks.

Regards,
Jon

 Any better idea?

 Best regards,
   Seb

 --
 Sebastien Vauban

Re: [O] using a simple numerical variable in an org text ocument

[Jonathan Leech-Pepin]

Hi,

Thorsten Jolitz writes:

 Matt Price mopto...@gmail.com writes:

 Hi,

 I'm making a very simple org-document -- a packing list for a trip.
 It has entries like

 - 4 mugs
 - for sleeping bags
 - 4 thermarest pads


 I'd like to replace the numbers there by a variable -- so if I make a
 list for 4 people, the number displayed will be '4'; but if the list
 is for 2 people, the number displayed will be 2.  Better would be if I
 could also do simple arithmetic manipulations (x * 6 dinners for a
 week...).  I there a really simple way to do this? if it's not really
 easy, it won't really seem worth it, but if it is really easy, I will
 use it a lot...

 Or, if you insist on checkboxes (private conversation), you might put this
 function in your .emacs and run it to replace all numbers (that are either
 factors or totals) with num * people (when people = 0) or with num / people
 (when people  0).


If you want to use checkboxes, couldn't you use a babel code block and
then =call= it on each entry?

#+begin_src org
  ,#+MACRO: count call_Sample(x=$1)[:results raw]
  
  ,* Test
  :PROPERTIES:
  :var:  people=5
  :END:
  
  - [ ] call_Sample(x=2)[:results raw] socks
  - [ ] call_Sample(x=1)[:results raw] toothbrushes
  - [ ] {{{count(3)}}} shoes

  ,#+name: Sample
  ,#+header: :var x=1 :results raw
  ,#+begin_src emacs-lisp
(* x people)
  ,#+end_src
  
  ,#+RESULTS: Sample
  5
#+end_src

You can then wrap it in a macro to avoid having to write out quite as
much per line (as the last entry demonstrates.

Then just adjust the value of the =:var:= property to match how many
people, and your export will provide the correct values


 #+begin_src emacs-lisp
   (defun tj/calc-total-items (people)
 Replace factor cookies with factor * people totals.
 (interactive NPeople: )
 (save-excursion
   (save-restriction
 (save-match-data
   (goto-char (point-min))
   (widen)
   (while (not (eobp))
 (and (org-at-item-checkbox-p)
  (looking-at
   (concat
\\(^[[:space:]]*-[[:space:]]
\\[[-X\s]\\][[:space:]]\\)
\\([[:digit:]]+\\)\\([[:space:]]+\\)))
  (let* ((num
  (string-to-number
   (match-string-no-properties 2)))
 (total
  (if (= people 0)
  (* num people)
(/ num (abs people)
(replace-match
 (format %s total) nil nil nil 2)))
 (forward-line))
 #+end_src

 #+results:
 : tj/calc-total-items


 Use either as 

 ,--
 | M-x tj/calc-total-items RET 7 RET
 `--

 or 

 ,--
 | C-7 M-x tj/calc-total-items RET
 `--

 in your org-buffer.

 When there are e.g. 7 people, this checkbox list 

 - [ ] 1 toothbrushes
 - [ ] 4 socks

 turns into 

 - [ ] 7 toothbrushes
 - [ ] 28 socks

 after applying the above command in this buffer, and the change is
 reversed when applying

 ,--
 | M-x tj/calc-total-items RET -7 RET
 `--

 or 

 ,--
 | C--7 M-x tj/calc-total-items RET
 `--

 afterwards. Note that you must stick to the format 

 ,--
 | - [ ] digit text 
 `--

 for this to work.

Regards,

--
Jonathan

Re: [O] Two questions about org-export-insert-default-template in new org-exporter

[Jonathan Leech-Pepin]

Hello,

Rasmus writes:

 Robert Goldman rpgold...@sift.info writes:

 1.  The original org-insert-export-options-template always inserted the
 template at the top of the file.  The new one inserts at point.  Since
 the options need to be at the top of the file, would there be any
 objection to making the new template inserter behave the same way?

 I can't reproduce your claim on Org v8.03.

 For instance this works great with html and LaTeX.

 #+BEGIN_SRC org
 * TODO my topic 
 this is my documents with garbage in the bottom 
 * hide the boring stuff  :noexport:
 #+TITLE: my boring title
 #+AUTHOR: my boring name 
 #+DATE: Another day at the office
 #+OPTIONS: toc:nil todo:nil
 #+END_SRC


I don't remember this being the case in previous versions either, I
usually had something along the lines of

#+BEGIN_SRC org
* Configuration 

 2.  Users can directly issue this command using M-x
 org-export-insert-default-template, since it's tagged as (interactive).
  Since this is possible, wouldn't it make sense to have the function
 query for the BACKEND argument when invoked interactively?

 Use the export dispatcher.  C-e # or C-e l # (for LaTeX).

 –Rasmus

Re: [O] Two questions about org-export-insert-default-template in new org-exporter

[Jonathan Leech-Pepin]

Oops, sent incomplete.

On 4 June 2013 14:19, Jonathan Leech-Pepin
jonathan.leechpe...@gmail.com wrote:

 Hello,

 Rasmus writes:

 Robert Goldman rpgold...@sift.info writes:

 1.  The original org-insert-export-options-template always inserted the
 template at the top of the file.  The new one inserts at point.  Since
 the options need to be at the top of the file, would there be any
 objection to making the new template inserter behave the same way?

 I can't reproduce your claim on Org v8.03.

 For instance this works great with html and LaTeX.

 #+BEGIN_SRC org
 * TODO my topic
 this is my documents with garbage in the bottom
 * hide the boring stuff  :noexport:
 #+TITLE: my boring title
 #+AUTHOR: my boring name
 #+DATE: Another day at the office
 #+OPTIONS: toc:nil todo:nil
 #+END_SRC


 I don't remember this being the case in previous versions either, I
 usually had something along the lines of

#+BEGIN_SRC org
,* Configuration :ARCHIVE:
,#+TITLE: TITLE
,#+AUTHOR: me
#+END_SRC

as the last headline in my file.

Regards,
Jon

 2.  Users can directly issue this command using M-x
 org-export-insert-default-template, since it's tagged as (interactive).
  Since this is possible, wouldn't it make sense to have the function
 query for the BACKEND argument when invoked interactively?

 Use the export dispatcher.  C-e # or C-e l # (for LaTeX).

 –Rasmus

Re: [O] New maintainer

[Jonathan Leech-Pepin]

Hello Bastien,


On 18 April 2013 12:53, Bastien b...@gnu.org wrote:

 Dear all,

 I'm stepping down as the Org maintainer.


Thank you for all the work you've done.


 Carsten accepted to step up, if the community agrees.
 Please raise your thumbs up or your concerns, if any.

 Thumbs up from me as well.


 I'm glad I had this opportunity to work as Robin and
 I'm even more glad Batman may strike back!

 :)

 --
  Bastien

 --
Jon

[O] Bug?: org-babel-load-file not autoloaded in Emacs 24.3

[Jonathan Leech-Pepin]

Hello all,

I currently have the vast majority of my .emacs configuration in .org
files that rely on =org-babel-load-file=.

Before updating to Emacs 24.3 I could rely on autoloads to complete
the initialization.  After updating today I get the following error:

=Symbol's function definition is void: org-babel-load-file=

Is it intentional that org-babel-load-file is no longer autoloaded and that
either (require 'org) or (require 'org-loaddefs) is needed to use it when
starting emacs?

Regards,

Jon

Re: [O] ox-html.el removal

[Jonathan Leech-Pepin]

Hello,

T.F. Torrey writes:

 Jambunathan K kjambunat...@gmail.com writes:

 Meanwhile, someone should fix up the FSF assignment notice on those
 files.  As far as I am concerned, it is a routine housekeeping thing and
 hasn't taken effect.  I am not assigning any copyright to FSF.

 Section 1a of the copyright assignment agreement is very specific:

 #+BEGIN_QUOTE:
   1.(a) Developer hereby agrees to assign and does hereby assign to FSF
 Developer's copyright in changes and/or enhancements to the suite of
 programs known as EMACS (herein called the Program), including any
 accompanying documentation files and supporting files as well as the
 actual program code. These changes and/or enhancements are herein called
 the Works.
 #+END_QUOTE:

 As a signed contributor, you have already assigned copyright of your
 changes and/or enhancements to Emacs to the FSF (and therefore to this
 community).  The agreement does not limit the assignment to those that
 land in an Emacs release, or those you don't change your mind about, or
 anything like that.  Any changes and/or enhancements to Emacs became
 property of the FSF from the moment you wrote them.

 Because you are not the copyright holder, it isn't even your prerogative
 to decide which license the code is released under.  It happens to be
 GPL, but the code is licensed by the copyright holder, which is the FSF,
 not you.

 Even listing you as an author in the file is a courtesy, not an
 obligation.

 Furthermore, any future code you might write concerning Org is also
 automatically property of the FSF, and by extension this community.  You
 have no rights to it, moral or otherwise.

 #+BEGIN_QUOTE:
 (b) The assignment of par. 1(a) above applies to all past and future
 works of Developer that constitute changes and enhancements to the
 Program.
 #+END_QUOTE:

Arguably there is no requirement that any code Jambunathan or any other
FSF contributor writes needs to be provided to Emacs/FSF.  If I write a
library expanding on existing content but wish to retain copyright for
myself rather than assign it to the FSF they cannot require me to do
otherwise as far as I know.  Only if I wish it to become part of Emacs
is that required.

However in this case, if you look at the earliest commits of the two
files in question (EXPERIMENTAL/org-e-html.el and
EXPERIMENTAL/org-e-odt.el) they were both added to Org with the lines:

;; Copyright (C) 2011-2013  Free Software Foundation, Inc.

Therefore I see that as meaning that they are copyright by FSF and the
copyright assignment cannot be revoked except by the holder, in this
case FSF.
[...snip]

 All the best,
 Terry

Regards,
Jon

Re: [O] [RFC] Org version of the Org manual

[Jonathan Leech-Pepin]

Hello Achim,

On 10 March 2013 08:24, Achim Gratz strom...@nexgo.de wrote:

 Thomas S. Dye writes:
  That works nicely.  I found the error and orgmanual.pdf is now produced
  without errors.

 Progress! :-)

 With the current version from git I cannot export to texinfo
 successfully, though, I get this error near the end of the export:

 Debugger entered--Lisp error: (wrong-type-argument stringp nil)
   string-match(\\`[ \n.]+ nil) (if (string-match \\`[ \n.]+ s)
   (setq s (replace-match  t t s))) org-trim(nil) (concat \n@item 
   (if tag desc) \n (org-trim contents) \n) (let* ((tag
   (org-element-property :tag item)) (desc (org-export-data tag info)))
   (concat \n@item  (if tag desc) \n (org-trim contents) \n))
   org-texinfo-item((item (:bullet -  :begin 41929 :end 42016
   :contents-begin 42016 :contents-end 42016 :checkbox nil :counter nil
   :hiddenp outline :structure ((40825 2 -  nil nil @@info:@kbd{@@C-c
   /@@info:}@@, ~org-sparse-tree~ 41031) (41031 2 -  nil nil
   @@info:@kbd{@@C-c / r@@info:}@@, ~org-occur~ 41929) (41929 2 - 
   nil nil @@info:@kbd{@@M-g n@@info:}@@ or @@info:@kbd{@@M-g
   M-n@@info:}@@, ~next-error~ 42016))…

 This may actually a bug in the texinfo exporter.


The error is actually on line 6069 of the manual.  The {{{vindex[...]}}}
line and
subsequent paragraph.  As far as the list is concerned there is no
associated
content for that list entry.  Indenting them appropriately to be recognized
as part
of the list allows for successful export.

This may also be partly a bug, should the exporter allow for a list item
without any contents?

Regards,

Jon

  Is the html version of the Org manual generated from the .texi source?
  If so, could you show me how to augment Makefile so the html
  document is generated by `make orgmanual'?  I want to check if the html
  document looks reasonable.

 I've extended the Makefile to approximate the one in doc/, HTML is
 produced both via makeinfo and as an export via ox-html.  To proceed in
 an orderly manner and prepare for an eventual integration into Org, can
 you please do the following in your Org clone:

 git checkout master
 git checkout -b orgmanual master
 git submodule add https://github.com/tsdye/orgmanual.git
 git commit -am 'make orgmanual/ a submodule'

 cd orgmanual
 git checkout -b orgmanual master
 git am orgmanual.patch



 cd ..
 git commit -am 'update submodule orgmanual'
 git am org.patch



 If you are unsure about any of this, please ask.  You can now edit/add
 these lines

 --8---cut here---start-8---
 .PHONY: orgmanual
 EXTRADIRS=orgmanual
 orgmanual:
 $(MAKE) -C $@
 --8---cut here---end---8---

 to the top of your local.mk and should now be able to do a make
 orgmanual.  Which types of documentation are produced can be controlled
 with ORG_MAKE_DOC (default is info pdf html), just like for the
 official manuals.  Also, make cleanall will now clean up in orgmanual
 also.  BTEST_POST should be configured to have a load-path pointing to a
 sufficiently advanced htmlize version for the HTML export.

  My next step will be to bring orgmanual up-to-date with the changes
  that have been made to org.texi since I started the translation several
  months ago.

 I'm not envious…


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

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

Re: [O] [RFC] Org version of the Org manual

[Jonathan Leech-Pepin]

On 10 March 2013 15:25, Achim Gratz strom...@nexgo.de wrote:

 Jonathan Leech-Pepin writes:
  The error is actually on line 6069 of the manual. The {{{vindex
  [...]}}} line and subsequent paragraph. As far as the list is
  concerned there is no associated content for that list
  entry. Indenting them appropriately to be recognized as part of the
  list allows for successful export.

 Thanks for tracking that down.

  This may also be partly a bug, should the exporter allow for a list
  item without any contents?

 Well it should maybe not allow for it, but I think it should either
 expect to get a nil in that situation or otherwsie not let the error
 propagate.  Anyway, it's great to have such a large and complex document
 available to train the exporter on.


The error is not actually within ox-texinfo in this case however I suspect.
The exact same code (at the location of the error in ox-texinfo) appears
within
ox-latex and ox-ascii.

`(org-trim contents)', which removes whitespace at start and end of string,
in this case with the string being the contents of the list item.  When
there is
no contents there is no string to clean up.

Regards,

Jon



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

 Waldorf MIDI Implementation  additional documentation:
 http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [O] src blocks in texinfo export

[Jonathan Leech-Pepin]

Hello Dario,

On 12 February 2013 17:09, Dario Hamidi dario.ham...@gmail.com wrote:


 Hello Jonathan,

  Using your patch as is would wrap the source blocks in both example and
  verbatim blocks.  If going with verbatim it would be better to remove all
  references to @example/@end example.

 I don't understand where the problem lies with having a `@verbatim'
 within a `@example'. Could you maybe explain to me why this is
 problematic?

 Using both environments seems to achieve the goal of having an idented
 source block in the resulting info file without having to further
 process the source block before export.

 Consider exporting

 #+BEGIN_SRC sh
 function fails
 {
 echo this causes an error with makeinfo
 }
 #+END_SRC

 with only the verbatim environment:

 File: test.info,  Node: Top,  Up: (dir)

 Manual
 **

 function fails
 {
 echo this causes an error with makeinfo
 }

 and with verbatim in example:

 File: test.info,  Node: Top,  Up: (dir)

 Manual
 **

  function fails
  {
  echo this causes an error with makeinfo
  }

  It should be possible to escape any braces or @ before inserting them
 into
  the
  example block to ensure there is no expansion.

 While it certainly is possible, it would also mean to properly escape
 *all* characters with a special meaning to TeX.  I suppose that making
 text containing such characters visible in a document without having to
 escape them is what the verbatim environment is for.

  The only differences in using @verbatim over escaping any characters in
  @example are the following:
- Tabs are treated as tabs and not as single spaces
- The code block is not indented.

 Preserving whitespace seems like a good idea when displaying python
 source code or makefiles.

 Dario


I've implemented a fix for this that should resolve the issue.  `@ { }` are
now
properly escaped before export within source blocks.  I didn't wrap the one
block in the other since the issue also existed within lisp blocks (where
inserting a verbatim block within a lisp block would have likely caused
issues
had someone wanted to extract any @lisp code from the info file.

Regards,

Jon

Re: [O] [RFC] Org version of the Org manual

[Jonathan Leech-Pepin]

Hello,

On 10 March 2013 16:23, Nicolas Goaziou n.goaz...@gmail.com wrote:

 Hello,

 Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:

  The error is not actually within ox-texinfo in this case however I
 suspect.
  The exact same code (at the location of the error in ox-texinfo) appears
  within
  ox-latex and ox-ascii.
 
  `(org-trim contents)', which removes whitespace at start and end of
 string,
  in this case with the string being the contents of the list item.  When
  there is
  no contents there is no string to clean up.

 I'm unsure about the part of the code you're referring to: in
 ox-latex.el, there is (and contents (org-trim contents)), which
 shouldn't generate an error.


Oops.  I'd forgotten to include the (and contents ...) around the (org-trim
contents).

Sorry for the noise.

Regards,

Jon

 Would you mind providing an ECM for the problem you're describing?

 Thank you.


 Regards,

 --
 Nicolas Goaziou

Re: [O] [RFC] Org syntax (draft)

[Jonathan Leech-Pepin]

Hello

On 10 March 2013 13:12, Achim Gratz strom...@nexgo.de wrote:

 Jambunathan K writes:
  Emacs lisp has a manual of it's own.  I don't see how Org export
  reference *cannot* end in Emacs.

 I said that I'm expecting these references to become part of the
 manual(s).  I still expect that and will try to help it along, but it
 doesn't necessarily need to take the exact sequence of events that I
 envisioned.


I have to agree with Bastien that they do not really fit into the main
Org manual.

Providing them with Emacs (so that they are immediately available) is
a good thing in my mind, however I would put them as a separate
document similarly to how the Elisp manual is separate.

Regards,

Jon


  Bastien is doing what(ever) suits his whims and you are approving of
  it.

 I haven't approved or disapproved anything.  I have only stated the
 plain fact that if my understanding of the future course of events is
 incorrect, then my comment does not apply (and conversely, if it does,
 then the issue I've stated needs to be dealt with).

  I disapprove of what you are doing, Achim.

 You're welcome.  (Sun Tzu, III/2)


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

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

Re: [O] [texinfo] Info links

[Jonathan Leech-Pepin]

Hello Tom.

On 21 February 2013 18:26, Thomas S. Dye t...@tsdye.com wrote:

 Hi Jon,

 Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:

  Hello Tom,
 
  On 21 February 2013 15:09, Thomas S. Dye t...@tsdye.com wrote:
 
  Aloha all,
 
  This link (which works correctly in the Org mode buffer):
 
  [[info:emacs#Indirect Buffers][GNU Emacs Manual]]
 
  exports to texinfo like this:
 
  @ref{top,GNU Emacs Manual,,emacs#Indirect Buffers,}
 
  when I was hoping to approximate this:
 
  @ref{Indirect Buffers,,,emacs,GNU Emacs Manual}
 
  Is this a bug, or should I be doing something differently?
 
  This was an oversight by me.  I only set ':' as the splitter in the
 path.
  I'm not at the machine that has the right SSH key to be able to push
  the fix, however if you change the # to : it should export properly (I'll
  add # as a marker to split on as well once I'm at the right machine).
 
  This will also work properly in Org to access the correct node.

 Yes, the : works fine everywhere.  Thanks!


I've added support for both # and : in info links.  So now it should
work either way.

Regards,

--
Jon


 All the best,
 Tom

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

Re: [O] [texinfo] Bug(?) in detailed node listing

[Jonathan Leech-Pepin]

Hi Tom,

On 21 February 2013 18:44, Thomas S. Dye t...@tsdye.com wrote:

 Hi Jon,
 [...]

 Based on this example from the Org manual, it looks as if the
 descriptions should start on column 32 or the third column after the end
 of the title, whichever is greater.


I've just pushed a fix for this.  It also introduces a new defcustom
to allow for choosing the column you want it to align at
(org-texinfo-node-description-column).

Regards,

--
Jon

 Thanks for your help on this.

 All the best,
 Tom

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

Re: [O] [org-e-texinfo] generate menu items

[Jonathan Leech-Pepin]

Hello,

On 23 February 2013 18:04, Nicolas Goaziou n.goaz...@gmail.com wrote:

 Hello,

 [...]

 I eventually added :OPTIONAL_TITLE: property. Get its parsed value with
 `org-export-get-optional-title' function.

 I patched ox-ascii, ox-latex and ox-html so they use it when building
 a TOC. I think only ox-odt and ox-texinfo are missing.

 Jonathan, could you have a look at it?


I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:.

Tom,

This will cause the menu titles to no longer export properly until you
change the property names.

Regards,

--
Jon


 Thank you.


 Regards,

 --
 Nicolas Goaziou

Re: [O] [org-e-texinfo] generate menu items

[Jonathan Leech-Pepin]

Hello

On 25 February 2013 11:09, Nicolas Goaziou n.goaz...@gmail.com wrote:

 Hello,

 Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:

  I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:.

 Thank you for looking into it.

 Though, please use `org-export-get-optional-title' function instead.
 OPTIONAL_TITLE property only contains the raw string. The function will
 return the parsed string.

 I actually did use (org-export-get-optional-title), I just wrote the wrong
information
in the changelog.  Sorry

Regards,

Jon


 Note: the function may be renamed soon, but I'll take care of that when
 it happens.


 Regards,

 --
 Nicolas Goaziou

Re: [O] how can I insert a new heading after all at this level?

[Jonathan Leech-Pepin]

Hello David,

On 19 February 2013 14:53, David Naumann naum...@cs.stevens.edu wrote:

 I'm a happy, frequent user of org mode but there's something I can't
 figure out from the manual.

 What I would like to be able to do is insert a new heading at the same
 level as current, _following_ all the others.  For example, with the
 cursor on the A in this tree:

 * top
 -  ** A
 ** B
 ** C
 * next

 I would like to insert a last sibling and move to it:

 * top
 ** A
 ** B
 ** C
 -  **
 * next

 Use case: adding to a very long chronological list.  I have not seen a
 quick way to do this using the structure motion/editing commands in
 the manual, without scrolling in one way or another.

 If you have a hint, please reply to my address; I'm not on this
 mailing list.


The following is a little long, however only one function is actually
interactive.

#+begin_src emacs-lisp
  (require 'org-element)

  (defun zin/org-next-element ()
Move to the end of the current element (start of next).
(let ((end (org-element-property :end (org-element-at-point
  (goto-char end)))

  (defun zin/org-element-check-element (type optional name)
Check if current element is of type TYPE.
  If not move to next element using `zin/org-next-element'.

  If NAME is non-nil, verify that the :name or :drawer-name
  property matches it.
(save-excursion
  (save-restriction
(save-excursion
  (org-up-element)
  (org-narrow-to-element))
   (catch 'element
 (while (not (eobp))
   (let ((cur-type (car (org-element-at-point)))
 ;; Allows for adaptation to non-headline cases.
 (cur-name (or (org-element-property
:name (org-element-at-point))
   (org-element-property
:drawer-name (org-element-at-point)
 (if (and (string= type cur-type)
  (string= name cur-name))
 (throw 'element (point))
   (zin/org-next-element

  (defun zin/org-element-start-or-end (start optional level)
Find start or ending point of an element's content.

  If START is non-nil, return the beginning of the content, if nil
  return the end.

  If LEVEL is equal to 1, parse the buffer for level 1 headlines.
  Any other value is ignored.
;; If level is 1, looking at top level headlines, there is no
;; containing element.
(if (and level
 (= 1 level))
(let* ((map   (org-element-map (org-element-parse-buffer) 'headline
(lambda (hl)
  ;; return a list of beginning and ending
  ;; points of all level 1 headlines.
  (list
   (org-element-property :begin hl)
   (org-element-property :end hl))) 'nil 'nil
'headline))
   ;; Find smallest (when start is 't) or largest (when
   ;; start is 'nil) point.
   (point (if start
  (apply 'min (mapcar 'car map))
(apply 'max (mapcar 'cadr map)
  point)
  ;; Not in a top level headline, deal with contents directly.
  (let ((top(org-element-property :contents-begin
(org-element-at-point)))
(bottom (org-element-property :contents-end
(org-element-at-point
(if start
top
  bottom

  (defun zin/org-add-heading (start optional title)
Create a new heading at the before or after all headings of current
level.

  If START is non-nil, the new heading will be the first in the
  list.  If nil it will be created after all the others.

  With optional TITLE, automatically insert the desired title,
  leaving the point on the following line.
(interactive P)
(org-back-to-heading)
(let* ((level (org-element-property :level (org-element-at-point)))
   (point (save-excursion
(ignore-errors (org-up-element))
(zin/org-element-start-or-end start level)))
   ;; Org-element minimal version of a headline at LEVEL with
   ;; TITLE (or blank)
   (headline `(headline (:level ,level :title ,(or title )
  (if start
  ;; If placing headline above existing headlines, ensure you do
  ;; not place it above the content of the parent headline.
  (progn
;; Search from top of content of parent headline.  Without
;; this it will put it above the current headline.
(goto-char point)
;; Do not check to make sure content is skipped if in a
;; level 1 headline, just return the start of the top
;; headline.
(unless
(= 1 level)
  (goto-char (zin/org-element-check-element headline
(goto-char point))
  (org-save-outline-visibility 't
 

Re: [O] [texinfo] Appendix?

[Jonathan Leech-Pepin]

Hello Tom,

On 22 February 2013 18:28, Jonathan Leech-Pepin 
jonathan.leechpe...@gmail.com wrote:

Hello Tom

On 22 February 2013 17:55, Thomas S. Dye t...@tsdye.com wrote:

Aloha Jon,

[...]
I don't understand.  This:

* Concept index
:PROPERTIES:
:TEXINFO_MENU_TITLE: Concept Index
:INDEX:cp
:END:

Gives me a numbered headline and an empty section.

If I add this:


@@info:@printindex cp@@

then an index is generated.  The headline is still numbered.

Am I doing something wrong?

I don't think so.  From the looks of things, index wasn't fixed along
with other properties to be uppercase in ox-texinfo.el.
I should be able to fix it on Monday (and make sure it now works),
along with the spacing of the detailed node listing.
Regards,
Jon


I've now fixed this.

Headlines with an :INDEX: property will now export as:

#+BEGIN_EXAMPLE
@unnumbered TITLE (or equivalent unnumbered subheading)

content of headline

@printindex INDEX (assuming INDEX is a recognized type, otherwise it
will simply be an unnumbered headline.

I've additionally added support for appendices.  These will export as
@appendix TITLE.

Indexes and appendices are mutually exclusive, indexes are tested for
first.

Regards,

Jon

Re: [O] [texinfo] Bug(?) in detailed node listing

[Jonathan Leech-Pepin]

Hello Tom,

On 25 February 2013 11:57, Thomas S. Dye t...@tsdye.com wrote:

 Hi Jon,

 Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:

  Hi Tom,
 
  On 21 February 2013 18:44, Thomas S. Dye t...@tsdye.com wrote:
 
  Hi Jon,
  [...]
 
  Based on this example from the Org manual, it looks as if the
  descriptions should start on column 32 or the third column after the end
  of the title, whichever is greater.
 
 
  I've just pushed a fix for this.  It also introduces a new defcustom
  to allow for choosing the column you want it to align at
  (org-texinfo-node-description-column).
 

 Nice.  Thanks!

 One nit: You have one space between the `::' at the end of a long title
 and the start of the description, where the Org manual has two spaces.


This should now be fixed (along with a logic error that was actually
inserting
description at column+5)

Regards,

Jon

 All the best,
 Tom

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

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

Hello Tom,

On 25 February 2013 12:52, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 IIUC, there is currently no support for @pxref{} in the texinfo
 exporter.  This is a texinfo @-command that does one thing in the info
 output and another in the LaTeX output.


Ultimately there is actually no real difference between see @ref{}
and @pxref{}.  I just checked using the first @pxref{} in org.texi
(Under Activation).

In org.texi it is shown as (@pxref{Conflicts}), in org.html it
becomes: (see a href=#ConflictsConflicts/a) while in the info
file (org) it is shown as (*note Conflicts::).

Opening the info file in Info (C-u C-h i path to info file), *node
Conflicts:: becomes see Conflicts.  Adding see manually
before *note does not change the output.  The same is the case for
@xref{}.  @xref{} adds See before the link in html/LaTeX, and
uses *Note in the info document; See [[link]] produces the same See in
html/LaTeX, and creates See *note in the info file (which is
inserted as See link in Emacs Info.

Yes the output is different if looking at the info file directly,
however when viewing it withing Emacs the text is consistent.

I didn't implement support for @xref{} or @pxref{} in the texinfo
exporter, because I could not find a way to reliably determine the
context so as to use the right type of link in the texi file.

Using occur there were already 47 cases in org.texi where [Ss]ee
@ref was used rather than the stylistically appropriate @pxref/@xref.

Regards,

Jon


 My idea is to create a custom link type, something like this:

 (org-add-link-type
pxref nil
(lambda (path desc format)
  (cond
   ((eq format 'html)
(format span class=\pxref\%s/span path))
   ((eq format 'latex)
(format \\ref{%s} path))
   ((eq format 'texinfo)
(format @pxref{%s,%s} path desc)

 I haven't tested this, but it should export approximately correctly and
 I'm confident I can get the export part working.

 What I can't figure out is how to have Org recognize that a link like
 this:

 [[pxref:Internal link]]

 is really an internal link, rather than an external link.  I'd like to
 be able to click on this and end up at Internal link in the Org
 buffer.

 Is this possible?  If so, can you point me to a solution?


All the best,
 Tom

 --
 T.S. Dye  Colleagues, Archaeologists
 735 Bishop St, Suite 315, Honolulu, HI 96813
 Tel: 808-529-0866, Fax: 808-529-0884
 http://www.tsdye.com

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

Hello,

On 25 February 2013 13:40, Subhan Tindall subhan.tind...@rentrakmail.comwrote:

 There are 4 different ref commands, all with slightly syntactic
 requirements and outputs when compiled using makeinfo.  I for one use
 @pxref{} a lot, and it has different requirements for placement than
 @ref or @xref (namely those two MUST have a . or , following the end
 of the ref)


Not entirely true, @ref{} will add a period after the end of the reference
in the info output
if no period or comma present, @xref{} needs a comma or period.  @pxref{}
can be
followed by a period, comma or right parenthesis, otherwise the info output
will include
a period as well.

So all three must have some sort of punctuation (or paren) following them
to ensure that
the references are clearly delimited.

Regards,


 8.1 Different Cross Reference Commands
 There are four different cross reference commands:
 @xref Used to start a sentence in the printed manual saying ‘See . . .
 ’ or an Info
  cross-reference saying ‘*Note name : node.’.
 @ref Used within or, more often, at the end of a sentence; same as
 @xref for Info;
 produces just the reference in the printed manual without a preceding
 ‘See’.
 @pxref Used within parentheses to make a reference that suits both an
 Info file and a
 printed book. Starts with a lower case ‘see’ within the
 printed manual. (‘p’ is
for ‘parenthesis’.)
 @inforef Used to make a reference to an Info file for which there is
 no printed manual.

 (from the Texinfo manual)

 On Mon, Feb 25, 2013 at 10:32 AM, Jonathan Leech-Pepin
 jonathan.leechpe...@gmail.com wrote:
  Hello Tom,
 
  On 25 February 2013 12:52, Thomas S. Dye t...@tsdye.com wrote:
 
  Aloha all,
 
  IIUC, there is currently no support for @pxref{} in the texinfo
  exporter.  This is a texinfo @-command that does one thing in the info
  output and another in the LaTeX output.
 
 
  Ultimately there is actually no real difference between see @ref{}
  and @pxref{}.  I just checked using the first @pxref{} in org.texi
  (Under Activation).
 
  In org.texi it is shown as (@pxref{Conflicts}), in org.html it
  becomes: (see a href=#ConflictsConflicts/a) while in the info
  file (org) it is shown as (*note Conflicts::).
 
  Opening the info file in Info (C-u C-h i path to info file), *node
  Conflicts:: becomes see Conflicts.  Adding see manually
  before *note does not change the output.  The same is the case for
  @xref{}.  @xref{} adds See before the link in html/LaTeX, and
  uses *Note in the info document; See [[link]] produces the same See in
  html/LaTeX, and creates See *note in the info file (which is
  inserted as See link in Emacs Info.
 
  Yes the output is different if looking at the info file directly,
  however when viewing it withing Emacs the text is consistent.
 
  I didn't implement support for @xref{} or @pxref{} in the texinfo
  exporter, because I could not find a way to reliably determine the
  context so as to use the right type of link in the texi file.
 
  Using occur there were already 47 cases in org.texi where [Ss]ee
  @ref was used rather than the stylistically appropriate @pxref/@xref.
 
  Regards,
 
  Jon
 
 
  My idea is to create a custom link type, something like this:
 
  (org-add-link-type
 pxref nil
 (lambda (path desc format)
   (cond
((eq format 'html)
 (format span class=\pxref\%s/span path))
((eq format 'latex)
 (format \\ref{%s} path))
((eq format 'texinfo)
 (format @pxref{%s,%s} path desc)
 
  I haven't tested this, but it should export approximately correctly and
  I'm confident I can get the export part working.
 
  What I can't figure out is how to have Org recognize that a link like
  this:
 
  [[pxref:Internal link]]
 
  is really an internal link, rather than an external link.  I'd like to
  be able to click on this and end up at Internal link in the Org
  buffer.
 
  Is this possible?  If so, can you point me to a solution?
 
 
  All the best,
  Tom
 
  --
  T.S. Dye  Colleagues, Archaeologists
  735 Bishop St, Suite 315, Honolulu, HI 96813
  Tel: 808-529-0866, Fax: 808-529-0884
  http://www.tsdye.com
 
 



 --
 Subhan Michael Tindall | Software Developer
 | s...@rentrakmail.com
 RENTRAK | www.rentrak.com | NASDAQ: RENT

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

(Here are the attached files, forgot to add them)

On 25 February 2013 15:24, Jonathan Leech-Pepin 
jonathan.leechpe...@gmail.com wrote:

 Hello,

 On 25 February 2013 14:01, Subhan Tindall 
 subhan.tind...@rentrakmail.comwrote:

 The point being that compiling .texinfo source into an Info file
 treats references differently. For example:
 (@pxref{my_node_name}).  will compile just fine.
 (@ref{my_node_name}). will not.


 Both work perfectly fine for me.
 makeinfo (GNU texinfo) 5.0


 There are also differences in case
 (see v. See, note v. Note), and differences in output by ref type
 depending on target output of file (info, DVI, HTML,...). For example,
 @pxref generates different punctuation for typeset v. info files, @ref
 does not generate a 'See ' in printed material while @xref does, etc.

 Although the differences are subtle, they really are not equivalent
 and should not be treated as such.


 With a slight amount of work on the user's part, they can be made
 functionally equivalent on export.

 Using the two attached minimal .texi files (good-ref.texi is using
 @xref/@pxref as is preferred while ref.texi is using @ref with
 appropriate See/see added in the text) and disregarding filename
 differences (since they are noted in the info output) I get the
 following differences:

  makeinfo --html --no-split good-ref.texi ref.texi
 0 Diffs

  makeinfo --docbook --no-split good-ref.texi ref.texi
 Filename ID appears in diff

  makeinfo --xml --no-split good-ref.texi ref.texi
 Filename difference.

 Links are different since TexinfoML does still distinguish xref/pxref
 and ref in how they create the links.

  makeinfo --no-split good-ref.texi ref.texi

 The info file does show the expected differences between the two
 documents, notably that the @xref{} becomes *Note while the
 equivalent See @ref{} becomes See *note with @pxref{}-*note vs
 see @ref{} - see *note.

 However once they are viewed within the *info* buffer (C-u C-h i
 good-ref.info/ref-only.info) the lines in question are visually
 identical since *Note becomes See and *note becomes see if there
 is not already see present.

 I will not disagree that @ref, @pxref and @xref are subtly different,
 however with slight user intervention @ref can be used in the same
 above locations by simply replacing:

 @xref{}  - See @ref{}
 @pxref{} - see @ref{}

 I had to compare these possible outcomes when working on the texinfo
 exporter.  Since links are parsed before being included in their
 paragraphs, I did not have a way to obtain context and therefore
 attempt to guess (and be successful) at which type of reference was
 intended by a link in Org.  Restricting it to @ref{} in all cases,
 even if it added a slight burden to the user (4 additional characters
 to type in Org) if they wanted to emulate @xref or @pxref was in my
 opinion the best choice.

 Regards,

 --
 Jon

 [...]




good-ref.texi
Description: TeXInfo document


ref.texi
Description: TeXInfo document

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

Hello

On 25 February 2013 16:34, Subhan Tindall subhan.tind...@rentrakmail.comwrote:

 I noticed you left out @inforef, was that by design?  It actually does
 behave quite differently than other members of the @*ref family, and
 the more arguments it gets the more different it looks IE Here's an
 example with a full 5 arguments:
 REF *note Arg2: (Arg4)Lore Ipsum.
  INFOREF *note Arg2: (Arg3)Lore Ipsum Arg4, Arg5


I omitted @inforef, @uref, @url @email by design because they are
external links in an org file and can be processed differently.

Org Links only have 2 arguments at most (destination and description)
so the additional arguments are skipped as well.

Info links are format: [[info:info-file:node][description] or
[[info:info-file#node][description]] so can provide the 3 arguments
by splitting between file and node.

Regards



 On Mon, Feb 25, 2013 at 12:29 PM, Jonathan Leech-Pepin
 jonathan.leechpe...@gmail.com wrote:
  (Here are the attached files, forgot to add them)
 
 
  On 25 February 2013 15:24, Jonathan Leech-Pepin
  jonathan.leechpe...@gmail.com wrote:
 
  Hello,
 
  On 25 February 2013 14:01, Subhan Tindall 
 subhan.tind...@rentrakmail.com
  wrote:
 
  The point being that compiling .texinfo source into an Info file
  treats references differently. For example:
  (@pxref{my_node_name}).  will compile just fine.
  (@ref{my_node_name}). will not.
 
 
  Both work perfectly fine for me.
  makeinfo (GNU texinfo) 5.0
 
 
  There are also differences in case
  (see v. See, note v. Note), and differences in output by ref type
  depending on target output of file (info, DVI, HTML,...). For example,
  @pxref generates different punctuation for typeset v. info files, @ref
  does not generate a 'See ' in printed material while @xref does, etc.
 
  Although the differences are subtle, they really are not equivalent
  and should not be treated as such.
 
 
  With a slight amount of work on the user's part, they can be made
  functionally equivalent on export.
 
  Using the two attached minimal .texi files (good-ref.texi is using
  @xref/@pxref as is preferred while ref.texi is using @ref with
  appropriate See/see added in the text) and disregarding filename
  differences (since they are noted in the info output) I get the
  following differences:
 
   makeinfo --html --no-split good-ref.texi ref.texi
  0 Diffs
 
   makeinfo --docbook --no-split good-ref.texi ref.texi
  Filename ID appears in diff
 
   makeinfo --xml --no-split good-ref.texi ref.texi
  Filename difference.
 
  Links are different since TexinfoML does still distinguish xref/pxref
  and ref in how they create the links.
 
   makeinfo --no-split good-ref.texi ref.texi
 
  The info file does show the expected differences between the two
  documents, notably that the @xref{} becomes *Note while the
  equivalent See @ref{} becomes See *note with @pxref{}-*note vs
  see @ref{} - see *note.
 
  However once they are viewed within the *info* buffer (C-u C-h i
  good-ref.info/ref-only.info) the lines in question are visually
  identical since *Note becomes See and *note becomes see if there
  is not already see present.
 
  I will not disagree that @ref, @pxref and @xref are subtly different,
  however with slight user intervention @ref can be used in the same
  above locations by simply replacing:
 
  @xref{}  - See @ref{}
  @pxref{} - see @ref{}
 
  I had to compare these possible outcomes when working on the texinfo
  exporter.  Since links are parsed before being included in their
  paragraphs, I did not have a way to obtain context and therefore
  attempt to guess (and be successful) at which type of reference was
  intended by a link in Org.  Restricting it to @ref{} in all cases,
  even if it added a slight burden to the user (4 additional characters
  to type in Org) if they wanted to emulate @xref or @pxref was in my
  opinion the best choice.
 
  Regards,
 
  --
  Jon
 
  [...]
 
 



 --
 Subhan Michael Tindall | Software Developer
 | s...@rentrakmail.com
 RENTRAK | www.rentrak.com | NASDAQ: RENT

Re: [O] pxref in texinfo export

[Jonathan Leech-Pepin]

Hello

On 25 February 2013 16:48, Subhan Tindall subhan.tind...@rentrakmail.comwrote:

 I don't think there is a specific context that can clearly separate
 them. The differences are largely semantic, not syntactic. What is
 needed is some sort of marker on the tag in the original file telling
  it what kind of link is to be used.


Agreed, although there is a semi-syntactic method potentially.



 On Mon, Feb 25, 2013 at 1:38 PM, Nicolas Goaziou n.goaz...@gmail.com
 wrote:
  Hello,
 
  Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:
 
  I had to compare these possible outcomes when working on the texinfo
  exporter.  Since links are parsed before being included in their
  paragraphs, I did not have a way to obtain context and therefore
  attempt to guess (and be successful) at which type of reference was
  intended by a link in Org.
 
  What kind of context would you need to know? The string that will be
  exported just before the current ref link?
 


 For @xref{} I would need to know if it was at the start of a sentence and
followed
by a comma or period.
For @pxref{} I would need to determine if it was at end of sentence,
mid sentence followed by a comma or within parentheses, and not preceeded by
see or see.  Although even this would not suffice, since there are
contexts where
@ref{} is the better choice.

Allowing for attributes on the links would allow for differentiating,
however the
alternative (which is the current behaviour) is just to create them all as
@ref{} and
then include the semantic context (See, see or nil) as appropriate for
export.

Regards,

Jon


  Regards,
 
  --
  Nicolas Goaziou



 --
 Subhan Michael Tindall | Software Developer
 | s...@rentrakmail.com
 RENTRAK | www.rentrak.com | NASDAQ: RENT

Re: [O] Online manual

[Jonathan Leech-Pepin]

Hello,

On Feb 24, 2013 11:48 AM, Sebastian Wiesner lunary...@gmail.com wrote:

 2013/2/24 Mike McLean mike.mcl...@pobox.com:
 
  On Feb 24, 2013, at 11:03 AM, Sebastian Wiesner lunary...@gmail.com
wrote:
 
  Hello,
 
  how is the online manual of Org mode [1] rendered?  Especially, how is
  the awesome table of contents on the right sight created?
 
  It is done through CSS and I do something similar with most of my HTML
exports. I have a custom CSS that I load by having the following in every
Org file.

 So is the Org manual written in Org?  I thought it was written in
 Texinfo.  After all, there is a Texinfo document in the Org sources
 [1]. Is this Texinfo document generated from some Org document?
 Generally, can Org be exported to Texinfo/Info?

 [1]: http://orgmode.org/cgit.cgi/org-mode.git/tree/doc/org.texi


Currently the manual is in info, however the new exporter has a texinfo
exporter and I know that Thomas Dye is working on converting it to org.

Regards,
Jon

Re: [O] [texinfo] Appendix?

[Jonathan Leech-Pepin]

Hello Tom

On 22 February 2013 16:15, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 I can't find a way to have the texinfo exporter start an appendix.

 * Last chapter
 blah blah

 * Appendix 1
 blah blah

 This will yield something like this:

 15 Last chapter
 ---
 blah blah

 16 Appendix 1
 -
 blah blah

 When I would instead like:

 A Appendix 1
 

 Assuming I'm not missing something, perhaps an attribute?


Appendixes should work as unnumbered headlines.   I don't remember
testing for that use specifically although there is a possible work-around
that will allow for unnumbered headlines for sure.

Indexes are always unnumbered, so using a property :INDEX: will
produce an unnumbered headline.  If you want it to insert one of the
default indexes you set the property to the appropriate key:
cp , fn , ky , pg , tp , vr

Regards,

Jon
--

 #+attr_texinfo :appendix t

 All the best,
 Tom

 --
 T.S. Dye  Colleagues, Archaeologists
 735 Bishop St, Suite 315, Honolulu, HI 96813
 Tel: 808-529-0866, Fax: 808-529-0884
 http://www.tsdye.com

Re: [O] [texinfo] Appendix?

[Jonathan Leech-Pepin]

Hello Tom

On 22 February 2013 17:55, Thomas S. Dye t...@tsdye.com wrote:

 Aloha Jon,

 Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:

  Hello Tom

  Appendixes should work as unnumbered headlines.   I don't remember
  testing for that use specifically although there is a possible
 work-around
  that will allow for unnumbered headlines for sure.
 
  Indexes are always unnumbered, so using a property :INDEX: will
  produce an unnumbered headline.  If you want it to insert one of the
  default indexes you set the property to the appropriate key:
  cp , fn , ky , pg , tp , vr
 

 I don't understand.  This:

 * Concept index
 :PROPERTIES:
 :TEXINFO_MENU_TITLE: Concept Index
 :INDEX:cp
 :END:

 Gives me a numbered headline and an empty section.

 If I add this:


 @@info:@printindex cp@@

 then an index is generated.  The headline is still numbered.

 Am I doing something wrong?


I don't think so.  From the looks of things, index wasn't fixed along
with other properties to be uppercase in ox-texinfo.el.

I should be able to fix it on Monday (and make sure it now works),
along with the spacing of the detailed node listing.

Regards,
Jon

 All the best,
 Tom

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

Re: [O] [texinfo] Info links

[Jonathan Leech-Pepin]

Hello Tom,

On 21 February 2013 15:09, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 This link (which works correctly in the Org mode buffer):

 [[info:emacs#Indirect Buffers][GNU Emacs Manual]]

 exports to texinfo like this:

 @ref{top,GNU Emacs Manual,,emacs#Indirect Buffers,}

 when I was hoping to approximate this:

 @ref{Indirect Buffers,,,emacs,GNU Emacs Manual}

 Is this a bug, or should I be doing something differently?

 This was an oversight by me.  I only set ':' as the splitter in the path.
I'm not at the machine that has the right SSH key to be able to push
the fix, however if you change the # to : it should export properly (I'll
add # as a marker to split on as well once I'm at the right machine).

This will also work properly in Org to access the correct node.

Regards,

Jon

 All the best,
 Tom

 --
 T.S. Dye  Colleagues, Archaeologists
 735 Bishop St, Suite 315, Honolulu, HI 96813
 Tel: 808-529-0866, Fax: 808-529-0884
 http://www.tsdye.com

Re: [O] [texinfo] Bug(?) in detailed node listing

[Jonathan Leech-Pepin]

Hello Tom,

On 20 February 2013 19:45, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 I can't figure out how to get the detailed node listing formatted
 correctly, so I want to call this a bug.  An example shows the problem:

 * Hacking::How to hack your way around
 * MobileOrg::  Viewing and capture on a mobile device
 * History and Acknowledgments::How Org came into being

  --- The Detailed Node Listing ---

 Introduction

 * Summary::  Brief summary of
 what \
 Org-mode does
 * Installation:: How to install a
 downl\
 oaded version of Org-mode


I'm guessing you mean the extra distance between the title and the
description of the listing?

This is not exactly a bug... In an attempt to get all the descriptions
to line up correctly I aligned them all based on the longest
subheading.  I'm guessing in this case there is an extremely long one
somewhere farther down.

I couldn't find any specification as to how far they should be aligned,
otherwise I would have set them to a specific column instead of
basing them on the longest headline.

I should be able to fix this to be more reasonable, however I would
need an opinion as to what distance would be appropriate/desireable.

Regards,

Jon

 Help?

 All the best,
 Tom

 --
 T.S. Dye  Colleagues, Archaeologists
 735 Bishop St, Suite 315, Honolulu, HI 96813
 Tel: 808-529-0866, Fax: 808-529-0884
 http://www.tsdye.com

Re: [O] [TEXINFO] Link bug

[Jonathan Leech-Pepin]

Hello,

On 16 February 2013 11:19, Thomas S. Dye t...@tsdye.com wrote:

 Nicolas Goaziou n.goaz...@gmail.com writes:

  Now, both the links are broken :(
 
  This is good news: the problem is now consistent ;)
 
  Anyway, these links export fine to LaTeX, HTML and ASCII, which means
  the problem now resides in ox-texinfo.el.
 

 Thanks Nicolas.  I'll wait for Jonathan to tweak ox-texinfo.


I've applied Nicolas' patch.  From testing the ECM it fixes the issue.

Regards,

--
Jon

 All the best,
 Tom

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

Re: [O] org-meta-return

[Jonathan Leech-Pepin]

Hello

On 20 February 2013 16:17, 42 147 aeus...@gmail.com wrote:

  M-RET M-right

 Appreciate the reply, but that's worse than what I was doing. M-right
 is not anywhere close to my high frequency areas of finger activity.
 I've changed all such keybindings.


You can also use TAB on an empty headline to cycle through the various
levels:
+1 level, -1 level, -2..n levels (until it reaches the top level *), and
then back
to the level it was created at.

Regards,

Jon

I notice that C-M-RET is undefined. If anyone wants to add the
 functionality as described in my original post, and bind it to that key
 chord, I would be grateful; in the meantime, I'll create a macro /
 interactive defun to do the same.

Re: [O] Anchors in texinfo export

[Jonathan Leech-Pepin]

Hello Tom,

On 13 February 2013 11:31, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 Currently, the texinfo exporter translates a dedicated target in a comment:

 # x-export-to-odt

 to this:

 @c x-export-to-odt

 It shouldn't need to be within a comment to work successfully in the
Texinfo exporter.
@anchor{} is not visible to the reader (unless looking at the .texi source)
so it won't
be impacted by being outside of a comment.


 I was expecting to see a texinfo anchor:

 @anchor{x-export-to-odt}

 There are a handful of these dedicated target comments cum anchors in the
 Org
 mode manual. I believe all of them are in places where it would be easy
 to replace them with links directly to the corresponding headline/node.

 Should I edit them away? Or, are dedicated target comments/anchors
 something the texinfo exporter should handle?


Regards,

Jon
--


 All the best,
 Tom

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

Re: [O] Anchors in texinfo export

[Jonathan Leech-Pepin]

Hi Tom,

On 14 February 2013 12:02, Thomas S. Dye t...@tsdye.com wrote:

 Hi Jon,

 Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:

 [...]

 Thanks.  I've moved the anchors outside comments and all is well.  In
 fact, the entire manual now exports texinfo that makeinfo compiles
 without any complaints.


That's great.  Out of curiosity does it also compile successfully to HTML?

Regards,

Jon
--

 All the best,
 Tom

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

Re: [O] Option H: and texinfo export

[Jonathan Leech-Pepin]

Hello Tom

On 13 February 2013 14:58, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 When the H: option is set to a number  4, the texinfo exporter
 generates a detailed node listing with links to nodes that texinfo
 doesn't recognize.  IIUC, texinfo recognizes nodes for chapter, section,
 subsection, and subsubsection, but not for any lower level divisions of
 the document.

 Is there a context where H:5..n would make sense in a document exported
 to texinfo?  If not, should the exporter behave differently in this
 instance?


I don't know of any case where there would be a reason to have n4 for
headline export to texinfo.


 These are just questions, not requests for changes to the code.  I have
 H:4 and things seem to be working beautifully :)


I've made a small change regardless, a constant with the max toc-depth
for texinfo (4), in case there ever is a time in the future where this depth
might have reason to change.  I've also set the detailed node listing to
limit
itself to whichever value is smaller (H: or 4).  This should prevent any
accidental generation errors due to H being too large.


Regards,

Jon
--

 All the best,
 Tom

 --
 T.S. Dye  Colleagues, Archaeologists
 735 Bishop St, Suite 315, Honolulu, HI 96813
 Tel: 808-529-0866, Fax: 808-529-0884
 http://www.tsdye.com

Re: [O] Offer for taking over maintainership

[Jonathan Leech-Pepin]

On 13 February 2013 13:08, Jambunathan K kjambunat...@gmail.com wrote:


 I offer to take over maintainership of Org.


I have to say -1 as well.


 Offer closes in 7 days.  Only pre-condition will be that Org-8.0 and
 subsequent releases happen under my supervision.

Is there something in particular about the forthcoming 8.0 that you would
want done differently from how it currently is being done?  Considering
Bastien's
current plan is to push towards releasing it in the near future.



 Principals and riff-raffs can PM me with your thoughts.  I defend your
  right to choose the maintainer or express yourself freely.


The tone in this bit, classifying readers of the list either as principals
(I'm assuming
this would be Bastien and others who are highly active in maintaining and
updating
Org) or riff-raff (meaning the rest of the user base?) is hardly endearing.

I appreciate the org-odt exporter, I haven't had much use for it but what I
have had to
use it for it worked perfectly.  However your attitude in the past has
often struck me as
abrasive or argumentative when there was little to no reason for it.
 Either there's some
underlying reason for your apparent dislike for Bastien and his approach to
maintaining
Org, or some argument in the past that I am not aware of.

Regardless, Bastien is doing a fine job from what I can see, he is
certainly actively assisting
users who post with questions or bugs, even when they occurred during a
time where he was
absent (with prior notice).  Perhaps he has not contributed to certain
aspects as others have,
however his presence and monitoring of the smaller aspects does allow for
further development
to proceed without being interrupted by every issue.

Regards,
Jon
--

Note: Anger is futile, particularly over the internet.
 --

Re: [O] src blocks in texinfo export

[Jonathan Leech-Pepin]

Hello Dario,

On 12 February 2013 10:36, Dario Hamidi dario.ham...@gmail.com wrote:

 Hello,

 I discovered a problem when exporting source blocks containing braces to
 texinfo using `ox-texinfo'.  The texinfo exporter wraps source blocks
 into a `example' environment, which takes care of source block
 indentation but doesn't allow any braces to occur in the contained text,
 since braces have a special meaning in TeX.

 After reading the `texinfo' manual, it became clear that literal examples
 should be exported also in a `verbatim' environment.  A patch making
 this change to the exporter is attached.



Using your patch as is would wrap the source blocks in both example and
verbatim blocks.  If going with verbatim it would be better to remove all
references to @example/@end example.

I had chosen to go with @example rather than @verbatim because it does state
that lisp blocks should be wrapped in @lisp which is synonymous to @example.

It should be possible to escape any braces or @ before inserting them into
the
example block to ensure there is no expansion.

The only differences in using @verbatim over escaping any characters in
@example are the following:
  - Tabs are treated as tabs and not as single spaces
  - The code block is not indented.

Regards,
Jon


  Dario

Re: [O] Tables in texinfo export

[Jonathan Leech-Pepin]

Hi Tom,

On Feb 12, 2013 8:56 PM, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 Is there a way to control column widths when exporting Org mode tables
 to texinfo?


By default the column widths are based on the longest entries in each
column.  However you can use:

#+attr_texinfo: :columns 0.4 0.6

Or whatever your desired ratios are.  These values do not need to add up to
1.

Regards,

--
Jon
 All the best,
 Tom
 --
 Thomas S. Dye
 http://www.tsdye.com

Re: [O] Fwd: Re: Bug? in texinfo exporter

[Jonathan Leech-Pepin]

On Feb 11, 2013 1:59 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:

 t...@tsdye.com (Thomas S. Dye) writes:

  Aloha Jon,

 [...]

  Yes, I believe you are right.  The commas are not the culprits.
  Apologies for the red herring.
 
  Perhaps Nicolas should revert the commit?  Could you check if this is
  the right thing to do?

 My fix isn't about the comma. Didn't it work?


Your fix seems to have worked from what I can see (it was what I was
thinking of fixing at least). The comma was Tom's initial guess.

  I *have* found a bug/limitation of the texinfo exporter.  If a link is
  split between two lines the exporter doesn't handle it correctly.  A
  split link is exported like @ref{A-split-link}, when it should be @ref{A
  split link}, I think.
 
  If this is a limitation, please let me know so I can put all the links
  on one line.

 There's no such limitation. Could you provide an ECM for that?

I think Tom might be referring to when a line is hard wrapped with M-q. It
seems to affect the description of the org link to escape the spaces. I'm
not sure what effect this has on export. From what Tom is saying it isn't
unescaping the text.

Regards,
Jon

 Regards,

 --
 Nicolas Goaziou

[O] Fwd: Re: Bug? in texinfo exporter

[Jonathan Leech-Pepin]

-- Forwarded message --
From: Jonathan Leech-Pepin jonathan.leechpe...@gmail.com
Date: Feb 9, 2013 8:57 AM
Subject: Re: [O] Bug? in texinfo exporter
To: Thomas S. Dye t...@tsdye.com
Cc:
Just realized I hit reply not reply-all

If Nick's fix fixes it do much the better.com but I'm pretty sure the comma
isn't the culprit.

Regards,
 Hello Tom,

 On Feb 8, 2013 10:11 PM, Thomas S. Dye t...@tsdye.com wrote:
 
  Aloha all,
 
  The following text:
 
LaTeX math snippets (see [[LaTeX fragments]])
 
  is being exported to texinfo like this:
 
@LaTeX{} math snippets (see @ref{@LaTeX{} fragments,})
   ^
 
  I think the marked comma is giving makeinfo a heartache.  Makeinfo
tells me:
 

 The issue is more likely that it is escaping LaTeX within the reference
while the headline had it literally.

 I'm not at a computer right now but I should be able to look into it and
hopefully fix it this week.

/Users/dk/org/orgmanual//orgmanual.texi:11726: Cross reference to
nonexistent node `@LaTeX{} fragments' (perhaps incorrect sectioning?).
 
  Help?
 
  All the best,
  Tom
 

 Regards,

 Jon

  --
  T.S. Dye  Colleagues, Archaeologists
  735 Bishop St, Suite 315, Honolulu, HI 96813
  Tel: 808-529-0866, Fax: 808-529-0884
  http://www.tsdye.com
 

Re: [O] bug#12905: 24.2.50; org: edit source block causes data loss

[Jonathan Leech-Pepin]

On 12 December 2012 16:05, Bernt Hansen be...@norang.ca wrote:

 Hi Bastien,

 I'm not sure if this is related or not - I don't have time to track down
 the offending commit right now.

 org-edit-special (C-c ') is currently broken in master.


I get the same thing when trying (C-c ') on the #+begin_src line.  When
trying
it within the body of the source block it works properly

 I get the following backtrace

 --8---cut here---start-8---
 Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil)
   copy-marker(nil t)
   org-edit-src-code()
   org-edit-special()
   call-interactively(org-edit-special nil nil)
 --8---cut here---end---8---

 GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11
 on raven, modified by Debian

 Org-mode version 7.9.2 (release_7.9.2-664-gb1f369 @
 /home/bernt/git/org-mode/lisp/)

 Thanks,
 Bernt


Regards,
Jon


 Bastien b...@altern.org writes:

  Hi Chong,
 
  Chong Yidong c...@gnu.org writes:
 
  Could you please take a look at Bug#12905?  If it causes data loss, I
  think it should be fixed in the emacs-24 branch.  Thanks.
 
  This is fixed, thanks for the heads up.
 
  I just merged the Org bugfix branch into emacs-24.
 
  I made one mistake: I backported Paul's fixes about whitespaces in
  our bugfix branch*, so those fixes are now in emacs-24 too, not in
  the trunk only.  I hope this won't create merge conflicts.
 
  * http://orgmode.org/cgit.cgi/org-mode.git/commit/?h=maintid=e5ea08

Re: [O] texinfo export of @@

[Jonathan Leech-Pepin]

Hello Tom,

On Dec 7, 2012 3:35 PM, Thomas S. Dye t...@tsdye.com wrote:

 Aloha Jon,

 With this macro:

 #+MACRO: code @@info:@code{$1}@@

 this Org source:

  {{{code([@@b])}}}

 is exported as:

  @code{[b]@}.

 Any idea how to get @code{[@@b]} instead?

You should be able to simply use ~@@b~ to create @code blocks


 All the best,
 Tom
 --
 T.S. Dye  Colleagues, Archaeologists
 735 Bishop St, Suite 315, Honolulu, HI 96813
 Tel: 808-529-0866, Fax: 808-529-0884
 http://www.tsdye.com


Regards,
Jon

[O] [new-exporter] Macro expansion does not allow for newlines '\n'

[Jonathan Leech-Pepin]

Hello all,

The new exporter does not properly parse \n characters in macro definitions.

In the old exporter the following:

#+MACRO: test hello\ngoodbye

{{{test}}}

exports to ASCII as:

hello
goodbye

In the new exporter (e-ascii) it exports as:

hello\ngoodbye

I've also reproduced this using e-pdf and e-texinfo.

Regards,

--
Jon

Re: [O] [org-e-texinfo] generate menu items

[Jonathan Leech-Pepin]

Hello Tom, Nicolas,

I've just pushed a change that should provide the desired results.

The optional title for the menu entries (as well as associated node
headings) can be set using the :TEXINFO_MENU_TITLE: property.

On 18 November 2012 11:22, Thomas S. Dye t...@tsdye.com wrote:

 Nicolas Goaziou n.goaz...@gmail.com writes:

  t...@tsdye.com (Thomas S. Dye) writes:
 
  Nicolas Goaziou n.goaz...@gmail.com writes:
 
  That's a bit of work, because, so far, node-property values are not
  parsed. So it would require to define a new class of node-properties:
  those with a parsed value. But then, how to decide which properties
 have
  their value parsed are parsed and which have not?
 
  Thanks for the information and explanation.  Back-end-specific
  properties should work nicely in this case.
 
  I'll wait to see what Jonathan thinks about the original query.
 
  Assuming :EXPORT_TITLE:, :EXPORT_AUTHOR:, :EXPORT_DATE: and this
  one, :EXPORT_TOC_ENTRY: (?), will be the only ones being parsed, I can
  give it a try.
 


If you do include these node properties I can then adjust the texinfo
exporter to use the generic TOC/Optional title property rather than a
backend specific one.


Regards,

--
Jon


  I would be consistent with #+caption[short]: long for other elements.
 
 
  Regards,

 I'm biased by LaTeX, which uses the optional argument for the TOC and
 running heads. Since the back-ends are free to use this optional entry
 as they please, and not only for the TOC, perhaps :EXPORT_SHORT_ENTRY:
 (because that is its usual function), or :EXPORT_OPTIONAL_ENTRY:
 (because the back-end has the option to use it where appropriate).

 All the best,
 Tom

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

Re: [O] [org-e-texinfo] Exporting email address

[Jonathan Leech-Pepin]

Hello Tom,

On Nov 18, 2012 1:29 PM, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 I have this in the Org file:

 @@info:@email{emacs-orgmode@@gnu.org}@@

 I expect to get this in the texi file:

 @email{emacs-orgmode@@gnu.org}

 Instead, I get this:

 @email{emacs-orgmodegnu.org@}


The issue is that the @@ is viewed as the end of the snippet and not as a
portion of it.

However I believe that the exporter can parse mailto links properly
[[Mailto: emacs-orgmode@gnu.org]] should work. I don't have access to my
computer right now so I can't check but I'll look at this as well as the
other points you've brought up during the week.

 In general, the export snippets work very well.  I think this might be a
 corner case caused by the '@@' in the argument to the texinfo @email
 command.  I don't know if this pops up elsewhere in texinfo.

 All the best,
 Tom
 --
 Thomas S. Dye
 http://www.tsdye.com


Regard,
Jon

Re: [O] org-entities for texinfo

[Jonathan Leech-Pepin]

Hello,

On 11 November 2012 15:13, Nicolas Goaziou n.goaz...@gmail.com wrote:

 Hello,

 t...@tsdye.com (Thomas S. Dye) writes:

  With the new exporter's texinfo back-end, I think org-entities and
  org-entities-user might usefully be augmented with the entities listed
  in Chapter 14 of the texinfo manual, Special Insertions.
 
  Or, is there some other Org mechanism that might be preferable?

 AFAIU, texinfo can handle UTF-8 characters with:

   @documentencoding UTF-8

 (see section 18.2 from texinfo manual). So I guess it's safe to rely
 on :utf-8 entities.

 However, special characters like @dots{} are usually handled with
 special strings mechanism, directly at the plain text transcoded (see
 `org-e-latex-plain-text' for example).



I believe I accounted for most of the special strings that are
directly transcoded in texinfo.  There may be some that are missing,
however they can be added directly in the document using the
=@@info:texinfo command@@= syntax (inline export snippets).

Are there any particular pieces of synxtax that you believe would be
useful to have added to org-entities that would also be useful in
other backends?


 Regards,

 --
 Nicolas Goaziou


Regards,

--
Jon

Re: [O] [new exporter][texinfo] Macro definition section

[Jonathan Leech-Pepin]

Hello,

On 11 November 2012 15:22, Thomas S. Dye t...@tsdye.com wrote:

 Aloha all,

 The texinfo source for the Org manual has a number of macro definitions
 for commands and keys between the end of the header (@finalout) and the
 beginning of the Copying section.

 The texinfo back-end for the new exporter doesn't have a slot here and
 I'm wondering if it needs one?





 All the best,
 Tom
 --
 T.S. Dye  Colleagues, Archaeologists
 735 Bishop St, Suite 315, Honolulu, HI 96813
 Tel: 808-529-0866, Fax: 808-529-0884
 http://www.tsdye.com

Re: [O] org-entities for texinfo

[Jonathan Leech-Pepin]

On 12 November 2012 12:41, Thomas S. Dye t...@tsdye.com wrote:

 Aloha Nicolas and Jon,

 Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:

  Hello,
 
  On 11 November 2012 15:13, Nicolas Goaziou n.goaz...@gmail.com wrote:
 
  Hello,
 
  t...@tsdye.com (Thomas S. Dye) writes:
 
   With the new exporter's texinfo back-end, I think org-entities and
   org-entities-user might usefully be augmented with the entities listed
   in Chapter 14 of the texinfo manual, Special Insertions.
  
   Or, is there some other Org mechanism that might be preferable?
 
  AFAIU, texinfo can handle UTF-8 characters with:
 
@documentencoding UTF-8
 
  (see section 18.2 from texinfo manual). So I guess it's safe to rely
  on :utf-8 entities.

 Yes, this seems to work fine. I was thinking about a back-end agnostic
 Org document, but I see that texinfo has its own suite of exporters, so
 there is no real need to export this document from Org using the other
 back-ends.


I believe most of the entities should be capable of exporting the
entities as well.

I also must stress that there's no guarantee that the texinfo exporter
will be able to generate documents that for anything other than info
use.  I haven't tested any documents with the other exporters, but I
focused on trying to provide successful export to info.


  However, special characters like @dots{} are usually handled with
  special strings mechanism, directly at the plain text transcoded (see
  `org-e-latex-plain-text' for example).
 
 
 
  I believe I accounted for most of the special strings that are
  directly transcoded in texinfo.  There may be some that are missing,
  however they can be added directly in the document using the
  =@@info:texinfo command@@= syntax (inline export snippets).
 

 This works well, too.  Thanks.

  Are there any particular pieces of synxtax that you believe would be
  useful to have added to org-entities that would also be useful in
  other backends?

 Not yet. I'm just getting started, but will let you know if I run into
 any.

 All the best,
 Tom

 
 
  Regards,
 
  --
  Nicolas Goaziou
 
 
  Regards,
 
  --
  Jon
  Hello,
 
  On 11 November 2012 15:13, Nicolas Goaziou n.goaz...@gmail.com
  wrote:
 
  Hello,
 
 
  t...@tsdye.com (Thomas S. Dye) writes:
 
   With the new exporter's texinfo back-end, I think org-entities
  and
   org-entities-user might usefully be augmented with the entities
  listed
   in Chapter 14 of the texinfo manual, Special Insertions.
  
   Or, is there some other Org mechanism that might be preferable?
 
 
  AFAIU, texinfo can handle UTF-8 characters with:
 
@documentencoding UTF-8
 
  (see section 18.2 from texinfo manual). So I guess it's safe to
  rely
  on :utf-8 entities.
 
  However, special characters like @dots{} are usually handled with
  special strings mechanism, directly at the plain text transcoded
  (see
  `org-e-latex-plain-text' for example).
 
 
 
  I believe I accounted for most of the special strings that are
  directly transcoded in texinfo.  There may be some that are missing,
  however they can be added directly in the document using the
  =@@info:texinfo command@@= syntax (inline export snippets).
 
  Are there any particular pieces of synxtax that you believe would be
  useful to have added to org-entities that would also be useful in
  other backends?
 
 
  Regards,
 
  --
  Nicolas Goaziou
 
 
 
  Regards,
 
  --
  Jon

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

Re: [O] Bug: New Exporter macro expansion

[Jonathan Leech-Pepin]

Hello,

On 6 October 2012 05:29, Nicolas Goaziou n.goaz...@gmail.com wrote:


 Hello,

 Sebastien Vauban
 wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:

 Did you go further in the thinking about what the macros will support in the
 future?  Such as: multiline macros, recursive macros, Babel blocks,
 etc.

 Macro expansion is already recursive.

 I think multiline macros are not needed, as they would be redundant with
 Babel. Despite what is written (for now) in the documentation, macros
 should be used for simple replacements, and Babel machinery for
 everything else.

 Though, you can have a macro expand to a one-line Babel call if you want
 to.


Thank you for the fix.

I do however have one other issue that I seem to recall working in the previous
exporter.

If I use #+INCLUDE: ./macros.org to store a list of common macros for
several files they will not appear in the exported document.  Is this intended?


 Regards,

 --
 Nicolas Goaziou



Regards,

--
Jon

[O] Bug: New Exporter macro expansion

[Jonathan Leech-Pepin]

Hello all,

I've found a few issues with the new exporter (tested using
org-e-latex and org-e-ascii) with regards to macro expansion on
export.

Using the minimal org file below with Org-mode version 7.9.2
(release_7.9.2-402-ge5e49e @ d:/Apps/Emacs/site-lisp/org/) certain
macros do not expand as expected.

#+begin_src org
  ,#+TITLE: Test
  ,#+author: testing
  ,#+macro: sample export this text
  ,#+macro: sample2 {{{sample}}} and this text
  ,#+macro: table | hello | goodbye |
  ,#+macro: table2 | hello | {{{sample}}} |

  ,* Sample headline

  {{{title}}}

  | Test  |1 |
  | {{{TITLE}}}   | {{{sample}}} |
  {{{table}}}
  {{{table2}}}
#+end_src

{{{title}}}, as well as {{{author}}} do not expand at all when
exporting.  In addition macros within table cells are treated as empty
text.

Regards,

--
Jon

Re: [O] org-metaup / org-metadown nerfed in 7.9.1

[Jonathan Leech-Pepin]

Hello Trevor,

On 26 September 2012 19:18, Trevor Vartanoff t...@codepuzzles.org wrote:

 Nicolas,


 Org has its own definition for a paragraph, which, apparently, doesn't
 match yours.

 A paragraph ends either at a blank line, at the end of the buffer, or at
 the start of another non-paragraph element. In particular, indentation is
 unrelated to paragraph boundaries.

 If your definition of a paragraph excludes every single publication of
 fiction and nonfiction in the history of written language, you may want to
 rethink your definition. I think Charles Dickens knew what a paragraph
 boundary was.

LaTeX uses the same paragraph definition, it splits on blank lines.
So does the old exporter.  By default if there is not a blank line
they treat it as a continuation of the previous.  If you treat it
otherwise how do you tell the difference between a manual break and
wrapped text that went to the next line?

 Actually, it's worse than that: even if you agree that everyone using a
 computer should now separate all paragraphs with a blank line, it still
 means that for any form of writing with closely packed separate lines, such
 as song lyrics, poetry, Shakespeare plays, or even basic lists of todo
 items, org-mode no longer lets you shift the lines around.

Basic lists of todo items will still work fine, Org treats list items
as their own elements and can be moved using org-metaup/down.  It will
also move paragraphs/verses for poetry and theater.  =transpose-lines=
( C-x C-t ) can be used to move the individual lines around
individually.

 I propose we implement an org-property value to decide which definition of
 element org-metaup should use. I'm glad to see an exception was made for
 node property, but that's only one of many, many problem cases.

 Regards,
 Trevor Vartanoff


Regards,
Jon

Re: [O] org-date-toggle-inactive

[Jonathan Leech-Pepin]

Hello Johan,

On 25 September 2012 14:09, Johan Sandblom j...@ndblom.se wrote:

 I wrote the following which allows me ctrl-c-ctrl-c on a date in an org
 file and thereby toggle the inactive state of the date. I find it useful
 when applying to courses that I am later [not] admitted to. Perhaps it is
 useful to someone else. Perhaps also there are obvious improvements to the
 code. Lastly, perhaps there is a better place to submit such snippets. I
 appreciate feedback.

 Regards, Johan

 (setq org-date-regexp
   [\\[][0-9]\\{4\\}-[0-9][0-9]**-[0-9][0-9] [[:alpha:]]\\{2,3\\}
 ?.*?[]])

 (defun org-at-date-p ()
   Am I inside an org date?
   (interactive)
   (save-excursion
 (if (looking-at org-date-regexp)
 t
   (if ( (skip-chars-backward -[:alnum:]: ) -40)
   (let ((left (- (point) 1)))
 (progn
   (search-backward-regexp [\\[] left t)
 (if (looking-at org-date-regexp)
 t)))

 (defun org-date-toggle-inactive ()
   (interactive)
   (if (org-at-date-p)
   (save-excursion
 (progn
   (search-backward-regexp [\\[])
   (if (string-equal  (match-string 0))
   (replace-match [)
 (replace-match ))
   (search-forward-regexp []])
   (if (string-equal  (match-string 0))
   (replace-match ])
 (replace-match ))
   t))
 nil))

 (add-hook 'org-ctrl-c-ctrl-c-hook
   'org-date-toggle-inactive)


You should be able to just use =org-toggle-timestamp-type=
instead of your snippet.  It performs the check and will toggle
back and forth between active and inactive timestamps.

(add-hook 'org-ctrl-c-ctrl-c-hook
  'org-toggle-timestamp-type)



 --
 Johan Sandblom, MD PhD
 m +46735521477
 What is wanted is not the will to believe, but the
 will to find out, which is the exact opposite
 --Bertrand Russell


Regards,

--
Jon

Re: [O] building tagcloud datastructure in elisp

[Jonathan Leech-Pepin]

Hello Marcello,

On 12 September 2012 14:41, Marcelo de Moraes Serpa celose...@gmail.com wrote:
 Hi list,

 How hard would it be to parse a bunch of org files and build an elisp data
 structure (Hash?) that represents a tagcloud? All tags in all headlines and
 subtrees should be taken into account (for all org files that are parsed).
 Could I use org-element to help me parse this or is there a better way?

 I'm just learning the org API, and I've only done a bunch of elisp hacks, so
 any insight would be greatly appreciated!

I'm learning as well, mostly by providing a feature I could use, or by
seeing a problem I find interesting and deciding I want to find a
solution to it.

 Thanks,

 - Marcelo.

Org-element doesn't seem to include tag-inheritance when providing
tags for a given headline, so counting inherited tags becomes slightly
more complex.

The following should provide what you want:

#+begin_src emacs-lisp
  (defun zin/org-tag-cloud-freq (optional inherit file)
Return an alist containing tag and frequency.

  When INHERIT is given, the frequency of a tag includes the number
  of subheadings (to indicate tag inheritance).  FILE allows for an
  arbitrary file to be retrieved and used for tag counting.
(interactive P)
(when file
  (find-file file))
(let* ((source (org-element-parse-buffer 'headline))
   (tags (org-element-map
  source 'headline
  (lambda (headline)
(let ((tags (org-export-get-tags headline source))
  (count (if inherit
 (length (org-element-map headline
'headline 'identity))
   1)))
  (list tags count)
   taglist)
  (setq taglist
(mapcar (lambda (s)
  (when (car s)
(loop for item in (car s) collect
  (list item (cadr s) tags))
  (setq taglist
(loop for item in taglist append item))
  (dolist (tag taglist result)
(let* ((tagitem (car tag))
   (tagcount (cadr tag))
   (sofar (assoc tagitem result)))
  (if sofar
  (setcdr sofar (+ tagcount (cdr sofar)))
(push (cons tagitem tagcount) result
  (format %s result)))

  (defun zin/org-tag-freq-list (files optional inherit)
List of files to be processed by `zin/org-tag-cloud-freq'.

  Returns a single alist of tag counts.
(let (result)
  (dolist (file files result)
(let ((entries (zin/org-tag-cloud-freq inherit file)))
  (loop for tag in entries do
(let ((tagitem (car tag))
  (tagcount (cdr tag))
  (sofar (assoc tagitem result)))
  (if sofar
  (setcdr sofar (+ tagcount (cdr sofar)))
(push (cons tagitem tagcount) result))
  (format %s result)))
#+end_src

The dolist loop for counting the tags themselves comes from
http://stackoverflow.com/questions/6050033/elegant-way-to-count-items.
There may be a cleaner way to obtain the list of tags and associated
counts but this provides the values.

The first function will work on any Org buffer to return the list of
tags while the second will do so for a list of org files (for example
org-agenda-files).

I hope this helps

Regards,

--
Jon

Re: [O] Activating modules before org-install (was: org-url-hexify-p is not respected)

[Jonathan Leech-Pepin]

Helo

On 11 September 2012 09:10, Memnon Anon
gegendosenflei...@googlemail.com wrote:
 James Harkins jamshar...@gmail.com writes:

 So then the question is, why was I getting the ID-style links in the
 first place? I hadn't loaded that module before (I didn't even know
 about load-library before).

 One short question: My ~/.emacs.d/init.el has these lines:
 ,
 | ;; modules got to be set _before_ org is loaded
 | (setq org-modules '(org-bbdb org-bibtex org-gnus org-info org-jsinfo
 | org-irc org-vm org-w3m org-crypt org-learn
 | org-collector org-habit org-depend org-timer))
 |
 | ;; load up Org-mode and Org-babel
 | (require 'org-install)
 `

 Is it true that modules got to be set _before_ org is loaded?
 IOW: May something weird happen if e.g. module org-id enters the game
 later on?

From what I saw when I was enabling org-habits, if you add it to the
org-modules list after calling (require 'org-install) it will not be
loaded.  So either update the modules list before requiring
=org-install=, use the customize interface or manually (require
'org-module).

 At quick glance on the manual, I saw nothing relevant.

 Of course, I could play it safe with M-x customize-variable org-modules,
 but ... well ... customize.

Regards,

--
Jon

Re: [O] makefile for v. 7.9.1 on Windows 7 doesn't work

[Jonathan Leech-Pepin]

Hello,

On Fri, Sep 7, 2012 at 8:33 AM, John Hendy jw.he...@gmail.com wrote:
 On Fri, Sep 7, 2012 at 2:13 AM, Bostjan Vilfan bostj...@alum.mit.edu wrote:
 Hello,
 I notice that the makefile in version 7.9.1 has been changed (with regard to 
 v. 7.8.11). When I tried to run it under Windows7, it didn't work (the 
 makefile for 7.8.11 ran OK). Can anyone provide some information?

 Can you provide more information? The error, what you were doing, etc?
 The last time I git pulled perhaps a week or so ago, I tried following
 Worg like so:[1]
 ,---
 | emacs -batch -Q -L lisp -l ../UTILITIES/org-fixup -f
 org-make-autoloads-compile
 `---

 It failed. I inspected the dit directory and noticed that it's  not
 ../UTILITIES anymore; all of the make stuff is in ../mk. Could that be
 the problem if you're following Worg?


If the problem is related to the missing =UTILITIES= directory, the
solution would seem to be just re-run the update.  I had that issue on
several machines, all of which complained the first time about the
missing =UTILITIES= directory and then ran successfullly on the
subsequent updates.

 As an aside, I just tried re-compiling to check and I noticed that if
 I follow Worg and cd into /path/to/org.git/mk and then run =emace
 -batch ... ../mk/org-fixup.el ...=, I get the error:
 ,---
 | Symbol's function definition is void: org-find-library-dir
 `---

 If I cd to /path/to/org.git and run the command with only one perios
 (=emacs ... ./mk/org-fixup.el ...=), then it works. But =M-x
 org-version= spits out something related to org-fixup and isn't a real
 version number.

 In any case, I can still compile as far as I know. Sorry if this
 wasn't your issue, but with the lack of details no one will be able to
 help you diagnose the problem.


 Best regards,
 John

 [1] http://orgmode.org/worg/org-hacks.html#compiling-org-without-make

 Regards,
 bostjanv


Regards,

--
Jon

Re: [O] makefile for v. 7.9.1 on Windows 7 doesn't work

[Jonathan Leech-Pepin]

Hello,

On Fri, Sep 7, 2012 at 9:05 AM, John Hendy jw.he...@gmail.com wrote:
 On Fri, Sep 7, 2012 at 7:45 AM, Jonathan Leech-Pepin
 jonathan.leechpe...@gmail.com wrote:
 Hello,

 On Fri, Sep 7, 2012 at 8:33 AM, John Hendy jw.he...@gmail.com wrote:
 On Fri, Sep 7, 2012 at 2:13 AM, Bostjan Vilfan bostj...@alum.mit.edu 
 wrote:
 Hello,
 I notice that the makefile in version 7.9.1 has been changed (with regard 
 to v. 7.8.11). When I tried to run it under Windows7, it didn't work (the 
 makefile for 7.8.11 ran OK). Can anyone provide some information?

 Can you provide more information? The error, what you were doing, etc?
 The last time I git pulled perhaps a week or so ago, I tried following
 Worg like so:[1]
 ,---
 | emacs -batch -Q -L lisp -l ../UTILITIES/org-fixup -f
 org-make-autoloads-compile
 `---

 It failed. I inspected the dit directory and noticed that it's  not
 ../UTILITIES anymore; all of the make stuff is in ../mk. Could that be
 the problem if you're following Worg?


 If the problem is related to the missing =UTILITIES= directory, the
 solution would seem to be just re-run the update.  I had that issue on
 several machines, all of which complained the first time about the
 missing =UTILITIES= directory and then ran successfullly on the
 subsequent updates.

 Can someone else confirm? I'm just pulled again and have no UTILITIES dir.


=UTILITIES/= was renamed =util/=, and then has since been moved to
=mk/=.  The results I had seen seemed to indicate that it couldn't
find a script in UTILITIES/ so it could not continue (because it had
been renamed but was being looked for in the old location).

Running it a second time simply removed the confusion as to the
location of the files and permitted the update to continue without
issues.

 John


 As an aside, I just tried re-compiling to check and I noticed that if
 I follow Worg and cd into /path/to/org.git/mk and then run =emace
 -batch ... ../mk/org-fixup.el ...=, I get the error:
 ,---
 | Symbol's function definition is void: org-find-library-dir
 `---

 If I cd to /path/to/org.git and run the command with only one perios
 (=emacs ... ./mk/org-fixup.el ...=), then it works. But =M-x
 org-version= spits out something related to org-fixup and isn't a real
 version number.

 In any case, I can still compile as far as I know. Sorry if this
 wasn't your issue, but with the lack of details no one will be able to
 help you diagnose the problem.


 Best regards,
 John

 [1] http://orgmode.org/worg/org-hacks.html#compiling-org-without-make

 Regards,
 bostjanv

Regards,

--
Jon

Re: [O] Alternate format for datetree

[Jonathan Leech-Pepin]

Hello,

On Thu, Sep 6, 2012 at 11:33 AM, John Hendy jw.he...@gmail.com wrote:
 On Thu, Sep 6, 2012 at 12:42 AM, c b 24x7x...@gmail.com wrote:
 Hi John and Nick,


[snip]


 * 09
 ** 05
 *** 2012 - Wednesday
  [2012-09-05 Wed 22:31] My first working month tree note
  [2012-09-05 Wed 22:35] My first working month tree note

 #2 The time always is reported as 22:31 (I guess that's the time I launched
 emacs). Is there a way for the time stamp to be corrected based on the
 current time? I generally leave emacs running for days together, so the time
 it's launched doesn't really work for me.

 Did you change the above to 21:35 or did it file like that? Not sure
 why H:M wouldn't expand to the current date. One thing that just
 occurred to me, however, is to replace that whole timestamp string
 with %%U% and Org will just expand it to a date+time stamp.

 Good luck,
 John

This is actually an issue with all of the backtick elements in the
capture template but it shows up most obviously in the timestamp
portion.  I only realized this after providing the solution that John
had referenced earlier in this thread.  Backticks are expanded on
evaluation and resolve to the specific value of their called portions.
 So for the headlines you will need to re-evaluate the template every
day to update it (or restart emacs).

For the timestamp itself you should be able to use the %U escape in
the capture template and it will insert the date and time on it's own.

Regards,

--
Jon

Re: [O] Question about org-habit and agenda views

[Jonathan Leech-Pepin]

Hello Thomas,

On Thu, Aug 16, 2012 at 10:28 AM, Thomas Moyer tommo...@gmail.com wrote:
 I have a set of habits that I do Monday through Friday (weekdays only) and
 the best suggestion I have found for this is to have 5 individual TODOs (one
 for each day). This seems to work well for the most part, but I have found
 one minor annoyance that I can't find a solution for.

 If I don't do one of the habits on Monday, that entry will appear as overdue
 until the next week on Monday when it comes around again. Is there a way to
 hide overdue habits? I don't want to mark it as DONE, since it wasn't even
 when it was late.


Couldn't you create a single habit that uses a .+1d/3d repeater?  It
would still show up on the weekend however it would not be listed as
overdue at that time.

On a slightly related note to the developers:  Is there any way that a
=skip-days= marker be added in Org?  This would allow for simpler
repeating tasks/habigs that are not to be done on weekends.

 As an example of what I current have, here is an excerpt for one habit:

 ** Notes
 *** TODO (M) Refile notes
 SCHEDULED: 2012-08-20 Mon ++1w
 :PROPERTIES:
 :STYLE: habit
 :END:
 *** TODO (T) Refile notes
 SCHEDULED: 2012-08-21 Tue ++1w
 :PROPERTIES:
 :STYLE: habit
 :END:
 *** TODO (W) Refile notes
 SCHEDULED: 2012-08-15 Wed ++1w
 :PROPERTIES:
 :STYLE: habit
 :END:
 *** TODO (R) Refile notes
 SCHEDULED: 2012-08-16 Thu ++1w
 :PROPERTIES:
 :STYLE: habit
 :END:
 *** TODO (F) Refile notes
 SCHEDULED: 2012-08-17 Fri ++1w
 :PROPERTIES:
 :STYLE: habit
 :END:

 So if I miss Monday, when I open my agenda on Tuesday, I currently see two
 entries for Refile notes. Ideally, I would like to only see the one for
 Tuesday, and then when the following Monday rolls around, I should see the
 Monday entry again, with the consistency graph showing that I missed last
 Monday.

 Thanks for the help!

 -Tom

 --
 Thomas Moyer
 tommo...@gmail.com


Regards,

--
Jon

Re: [O] Using org-mode as day planner

[Jonathan Leech-Pepin]

Hi,

On Fri, Aug 10, 2012 at 8:46 AM, John Hendy jw.he...@gmail.com wrote:
 On Fri, Aug 10, 2012 at 3:09 AM, Bastien b...@gnu.org wrote:
 Hi Jack,

 Jack Erwin j...@jugband.net writes:

 So, a couple of questions:

 1) Is this a sane approach?  My elisp is average at best, and the
 org-mode devs could probably think of a more graceful way to do this.

 I don't know.

 If I were you, I would give Org a little more time before trying to
 make it behave as planner behaves.

 Also, you might be interested in org-datetree.el, which helps storing
 things relatively to a date, which sounds a bit more `à la planner'.

 Out of curiosity, do date trees currently have any built in search
 functions or sparse tree searching ability? I currently use timestamps
 to capture things under the current month like this:

 * Journals
 ** 2012 August
 *** [2012-08-09 Fri] Did something
 - Notes
 - About
 - What I did

 This is nice as I need to print my notes for an intellectual property
 documentation notebook. I have a recurring deadline todo to remind me
 to print my orgmode notes and permanently tape them in my IP notebook.
 With timestamps (and the new sparse tree time functionality you
 added!) I can just search for all time stamps after my last completion
 date, mark any relevant with :export: and am on my way. When done, I
 can just replace-string :export: -  and the file is back to normal.

 Date trees would make this easier as I like using capture... but I
 don't like having to change my .emacs each month to make the
 adjustment of =** July 2012= as the target headline to =August 2012=.
 Date trees are the obvious way to be able to do this, but they don't
 have any of the neat search functionality that I know of.


You could try replacing Current Month with =,(format-time-string
%B)= in your capture template (just make sure to use a backtick
rather than a quote.  The snippet below would provide just such a
capture template that expands to Month Year automatically
without any intervention on a monthly or annual basis.

It doesn't include the inactive timestamp, or any other markings, but
those can be easily added or adapted from the existing template.

#+begin_src emacs-lisp
(setq org-capture-templates
  `((t
 Test
 entry
 (file+headline ~/test/test-capture.org
,(format %s %s
 (format-time-string %B)
 (format-time-string %Y))
#+end_src


 Thanks,
 John


   
 http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=lisp/org-datetree.el;hb=HEAD

 2) Is there a reason that the org-agenda-after-show-hook is only called
 when using org-agenda-goto and not org-agenda-switch-to, or is this a
 bug?

 A leftover, fixed now, thanks!

 --
  Bastien



Regards,

--
Jon

Re: [O] starting value for ordered lists?

[Jonathan Leech-Pepin]

Hello,

On Wed, Aug 8, 2012 at 2:24 PM, Matt Price mopto...@gmail.com wrote:
 Hi,

 in the org manual (http://orgmode.org/manual/Plain-lists.html) i read that I
 can start an ordered list at a particular number using an [@20] syntax:

 If you want a list to start with a different value (e.g. 20), start the text
 of the item with [@20]4. Those constructs can be used in any item of the
 list in order to enforce a particular numbering.

 I think I'm not understanding somehting though, as if I try this:

 [@13]. thirteenth item


The [@#] syntax has to come after the list item and before the item's
text.  The following was created using Alt+Enter on each line, and
typing the content, the numbers automatically recalculate when you
create the next entry with Alt+Enter.

#+begin_src org
  1. Test item 1
  3. [@3] Item 3
  4.
  10. [@10] Item 10
  11.
#+end_src

 org doesn't seem to recognize the line as a list item.  I'm running a pretty
 recent org 7.8.11 from git.  I'm sure I'm just reading the manual wrong --
 any hints? thanks
 Matt


Regards,

--
Jon

Re: [O] are super-hidden technical blocks required?

[Jonathan Leech-Pepin]

Hello,

On Sun, Aug 5, 2012 at 11:01 PM, Ilya Shlyakhter ilya_...@alum.mit.edu wrote:
 On Sun, Aug 5, 2012 at 10:46 PM, Torsten Wagner
 torsten.wag...@gmail.com wrote:
 I can see the point that the property drawer header can be annoying
 too. Actually, when I used orgmobile for the first time I was not too
 happy to see all this property drawers suddenly appearing in my files.

 Alternatively to a new kind of drawer, I would think of the
 HIDDEN_PROP: line and an additional method which hides a drawer even
 more if it only contains hidden property elements. That could be done,
 for example, by the already mentioned custom face.

 That is, a drawer is clearly visible if it contains properties intend
 to be read/changed by the user (not marked invisible).
 A drawer is less visible, if it contains only properties marked as hidden.

 That would be great.  Except, if a PROPERTIES drawer holds only hidden
 properties,
 it would be best to completely hide the :PROPERTIES: line (using
 outline-flag-region), rather than display it in
 a dimmed font.  So that, unless you explicitly ask to reveal these
 lines, you edit the file as if they weren't there.


The issue I can see with completely hiding :PROPERTIES: line is
that you would then run the risk of adding text at the wrong
location (between the headline and the drawer for example).  At
the moment when the drawer is folded you know if the point is
before, within or after the drawer (even though you still can
remove parts of :end: by accident with backspaces), if it isn't
visible at all you don't have that ability.

Re: [O] Fwd: Export to Texinfo

[Jonathan Leech-Pepin]

Hello,

On Fri, Aug 3, 2012 at 4:41 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
 Hello,

 Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:

 Nested lists do work with only a small issue I can see at the moment,
 if there are no blank lines between the items in org there are none in
 the info file either, however there are 2 blank lines at the end of
 the nested list (end of nested list+end of parent item).

 By default, Org export preserves the number of blank lines during
 conversion.  If no blank line separates two elements in the Org buffer,
 no blank line will separate their transcoded version.

 You can change this by using filters.  For example md back-end
 enforces at least one blank line between elements (see
 `org-md-separate-elements') and e-ascii back-end normalizes the number
 of blank lines after an headline (see
 `org-e-ascii-filter-headline-blank-lines').

 Filters are installed by :filters-alist keyword in
 `org-export-define-backend' and `org-export-define-derived-backend'.


I thought I'd set it to normalize (set a filter similar to the
one in org-e-ascii), but I must have gotten some part not quite
right.  I'll look it over again.

 When I export the attached .org file the only difference I get from
 your .texi is the AUTHOR and the chapter/sections are numbered rather
 than unnumbered (and the level 4 headline is an enumerate rather than
 an itemize).

 Ideally, for listified headlines, list type (ordered or not) should be
 determined by `org-export-numbered-headline-p' predicate.


They do follow the numbered/unnumbered settings.  When I exported
every headline (listified or otherwise) was numbered, in
Bastien's example they were all unnumbered, so it was consistent.


 Regards,

 --
 Nicolas Goaziou

Regards,

--
Jon

Re: [O] are super-hidden technical blocks required?

[Jonathan Leech-Pepin]

Hi,

On Mon, Jul 30, 2012 at 10:42 AM, Ivy Foster joyfulg...@archlinux.us wrote:
 On 30 Jul 2012, at 11:26 am +0900, Torsten Wagner wrote:
 Hi,

 Hi,

 [Because of the problems of syncing and interaction with
 third-party programs] I was wondering if it would be time
 to switch org-mode from text to some sort of XML.

 I mostly lurk on this list, but reading the preceding
 proposal I figured I should note that, as a user, one of the
 key features of org-mode is its lovely simplicity of syntax
 and interface. If I really wanted to keep my files in
 hand-hacked or generated XML, I could, but I'd much rather
 keep 'em in, well, org (-: .

 Would it help [alleviate the problem of property-blocks
 containing mixed user  technical data] to introduce a
 technical-property block which only contains information
 intend to be used by other programs and parsers?

 Sounds like an interesting idea.

It sounds interesting however my first instinct is that it will not be
easy to make the distinctions.  Is :ID: meant as technical-data or
user-data?  Columns and Archive properties are more 'technical', yet
they are for use by Org.  With the new exporter/org-element you
retrieve the properties using =org-element-property= so the unneeded
properties don't need to be parsed by the exporters.

 This blocks could be hidden under all normal means unlike
 really someone want to see them and hit a special
 key-combo.

 Hmm, personally I'd rather have it visible but clearly
 labeled. Transparency is nearly always a good thing.


Agreed.  If it's there I'd want to know it was there.  the :ARCHIVED:
tag does well enough at keeping content hidden for that purpose, but
you still see that it is present.  (So just don't open the drawer
unless you need it.)

 It's great that you're thinking about this stuff, and I'll
 look forward to seeing where these ideas go.

 Cheers,
 iff


Regards,
Jon

[O] [new exporter] Links in definition list titles are not exported

[Jonathan Leech-Pepin]

Given the org file

#+begin_src org
  ,* List Test
  ,** Plain List
  ,- A
  ,- [[http://www.google.com][google]]
  ,- [[http://www.google.com]]
  ,** Ordered List
  ,1. A
  ,2. [[http://www.google.com][google]]
  ,3. [[http://www.google.com]]
  ,** Definition List
  ,- A :: A
  ,- [[http://www.google.com][google]] :: Google
  ,- [[http://www.google.com]] :: google
#+end_src org

If I try to export to e-ascii =M-x org-export-dispatch RET A= I obtain
the following export (omitting TOC and title)

#+begin_ascii
  1 List Test
  ===

  [google] http://www.google.com

  1.1 Plain List
  ~~

- A
- [google]
- [http://www.google.com]


[google] http://www.google.com


  1.2 Ordered List
  

1. A
2. [google]
3. [http://www.google.com]


[google] http://www.google.com


  1.3 Definition List
  ~~~

A: A
[[http://www.google.com][google]]: Google
[[http://www.google.com]]: google
#+end_ascii

This also occurs in e-html and e-latex.  In the old exporter these
would have also been formatted the same way they are in ordered and
plain lists.

Is this change by design?

Regards,

Jon

Re: [O] Updating orgmode

[Jonathan Leech-Pepin]

Hello,

I had a similar issue when setting up Org on a Debian system lately.
For some reason Emacs was not adding a =subdirs.el= file to
=/usr/share/emacs/site-lisp/=.

Including the following provided the desired result:

,---(/usr/share/emacs/site-lisp/subdirs.el)---
| ;; -*- no-byte-compile: t -*-
| (if (fboundp 'normal-top-level-add-subdirs-to-load-path)
| (normal-top-level-add-subdirs-to-load-path))
`-

Regards,

Jonathan

On Thu, Jun 7, 2012 at 9:09 PM, Vikas Rawal
vikasli...@agrarianresearch.org wrote:
 I have a debian system. I am trying to update orgmode using git. But
 M-x org-version continues to show me version 7.7. How do I find where
 is it picking up this version from? It seems to me that this is the
 default version that shipped with my emacs. Debian repository has a
 more updated version (7.8.09) in its repositories. But I do not see
 much point in install it.

 I could compile org correctly. The compiler seems to have installed
 orgmode in /usr/share/emacs/site-lisp/org. But somehow emacs does not
 seem to be picking it  up from there.

 Will much appreciate help.

 Thanks,

 Vikas

Re: [O] make doc fails on current head

[Jonathan Leech-Pepin]

I can confirm it's fixed

And thanks for the answer, hadn't realized you could use @# and $# for
references.

On Fri, Jun 1, 2012 at 8:56 AM, Bastien b...@gnu.org wrote:
 Nick Dokos nicholas.do...@hp.com writes:

 Bastien b...@gnu.org wrote:


 So what does @@#$2 really means?  Does the first @ stand for This is
 a field coordinate and the rest for the coordinates range itself?

 @# is the current row number, so @@#$2 is a reference to the current row,
 second column.

 Got it, thanks to you and Michael for the detailed answers.

 --
  Bastien

[O] make doc fails on current head

[Jonathan Leech-Pepin]

Hello,

Under the current git head (4144c55) I get the following error when
trying to run =make doc=.

#+begin_src sh
  ~/build/org-mode $ make doc
  /usr/bin/make -C doc info
  make[1]: Entering directory `/cygdrive/d/Users/jleechpe/build/org-mode/doc'
  makeinfo --no-split org.texi -o org
  org.texi:2450: Unknown command `#$2)'.
  makeinfo: Removing output file `org' due to errors; use --force to preserve.
  Makefile:53: recipe for target `org' failed
  make[1]: *** [org] Error 1
  make[1]: Leaving directory `/cygdrive/d/Users/jleechpe/build/org-mode/doc'
  targets.mk:76: recipe for target `info' failed
  make: *** [info] Error 2
  ~/build/org-mode $
#+end_src

If I revert to =git checkout HEAD~1= make doc succeeds as it had previously.

Regards,

Jonathan

Re: [O] Windows (Cygwin) make: Works, but org-release(void)

[Jonathan Leech-Pepin]

Hello,

I haven't had any issues with Org and Cygwin lately.  I did however
come across this issue on a fresh install of Debian last week.

I was able to resolve it by adding =(require 'org-install)= to the
initialization (or calling it manually from the *scratch* buffer)
before checking the version.

Do you have (require 'org-install) in your initialization file
already?  And if not does it fix the issue?

Regards,

Jonathan

On Tue, May 29, 2012 at 1:15 AM, William Crandall bc3141...@gmail.com wrote:

 Hello,

 I know this has been an issue:
 http://lists.gnu.org/archive/html/emacs-orgmode/2012-05/msg00552.html
 http://lists.gnu.org/archive/html/emacs-orgmode/2012-04/msg01144.html

 So I was glad to get Cygwin to make the current org-mode master (git),
 seemingly with success. But restarting emacs brings up:


 Debugger entered--Lisp error: (void-function org-release)
   org-release()
   org-version()
   (if (fboundp (quote org-version)) (org-version) (Unknown))
   (format Generated by Org mode %s in Emacs %s. (if (fboundp
         (quote org-version)) (org-version) (Unknown)) emacs-version)
   eval((format Generated by Org mode %s in Emacs %s. (if (fboundp
         (quote org-version)) (org-version) (Unknown)) emacs-version))

 --

 And M-x org-version RET gives:

     org-version: Symbol's function definition is void: org-release

 Three listings follow:

 1. Excerpts from make
 2. The generated lisp/org-version.el:
 3. *Messages* from start up
 4. Full debugger stack trace

 Many thanks for any guidance!

 -BC

 Org-mode: 7.8.11 (release_7.8.11-16-ge67734)
 Emacs: 24.1.50.1
 Windows 7

 --

 1. Excerpts from make


 $ make -version
 GNU Make 3.82.90
 Built for i686-pc-cygwin
 Copyright (C) 2010  Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.


 $ make
 ==
 = Invoke make help for a synopsis of make targets. =
 = Created a default local.mk template.   =
 = Setting oldorg as the default target.    =
 = Please adapt local.mk to your local setup! =
 ==
 make -C doc clean;  make -C lisp clean;
 make[1]: Entering directory
      `/cygdrive/g/dev/bin/emacs/.emacs.d/org-7.8.11-dev/doc'
 rm -f org *.pdf *.html *_letter.tex org-version.inc \
   *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.pg *.pgs \
   *.toc *.tp *.tps *.vr *.vrs *.log *.html *.ps
 make[1]: Leaving directory
      `/cygdrive/g/dev/bin/emacs/.emacs.d/org-7.8.11-dev/doc'
 make[1]: Entering directory
      `/cygdrive/g/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp'
 rm -f org-version.el org-install.el org-version.elc org-install.elc
 rm -f *.elc
 make[1]: Leaving directory
      `/cygdrive/g/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp'
 make -C lisp compile
 make[1]: Entering directory
      `/cygdrive/g/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp'
 rm -f org-version.el org-install.el org-version.elc org-install.elc
 org-version: 7.8.11 (release_7.8.11-16-ge67734)
 Loading g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org-compat.el
 (source)...
 Loading g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/UTILITIES/org-fixup.el
 (source)...
 Saving file g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org-version.el...
 Loading vc-git...
 Wrote g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org-version.el

 org-install: 7.8.11 (release_7.8.11-16-ge67734)   
 Loading g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org-compat.el
 (source)...
 Loading g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/UTILITIES/org-fixup.el
 (source)...
 Generating autoloads for ob-C.el...
 Generating autoloads for ob-C.el...done
 Generating autoloads for ob-R.el...
 Generating autoloads for ob-R.el...done

 [...]

 Saving file g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org-install.el...
 Loading vc-git...
 Wrote g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org-install.el
 emacs -batch -Q  --eval '(add-to-list '''load-path .)'
        --eval '(batch-byte-recompile-directory 0)'
 Checking g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp...
 Compiling g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/ob-C.el...

 [...]

 Compiling g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org-xoxo.el...
 Wrote g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org-xoxo.elc
 Compiling g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org.el...
 Wrote g:/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp/org.elc
 Done (Total of 110 files compiled, 2 skipped)
 make[1]: Leaving directory
      `/cygdrive/g/dev/bin/emacs/.emacs.d/org-7.8.11-dev/lisp'
 make -C doc info
 make[1]: Entering directory
      `/cygdrive/g/dev/bin/emacs/.emacs.d/org-7.8.11-dev/doc'
 org-version: 7.8.11 (release_7.8.11-16-ge67734)

 makeinfo --no-split 

Re: [O] Variable `org-mobile-directory` must point to an existing directory. Multiplatform setup, howto

[Jonathan Leech-Pepin]

Hello,

I think by default Windows tries to treat C:\ as ~ when it isn't
explicitly defined beforehand.

If you evaluate the following, does it give the same Windows path as
to the actual folder?

#+begin_src emacs-lisp
  (expand-file-name ~/Dropbox/MobileOrg)
#+end_src

If not you'll want to try one of the following:

1) Set the Windows Environment Variable HOME to the desired location
(C:\Users\username for example)
2) Move your Dropbox folder to the location shown by the above code
snippet, it should then recognize it.
3) Replace =~/Dropbox/= in your configuration with the full path to
the Dropbox folder.

Regards,

Jonathan

On Tue, May 29, 2012 at 3:17 AM, Ian Barton li...@wilkesley.net wrote:
 On 28/05/12 15:45, Orlando wrote:

 Ian Bartonlistsat  wilkesley.net  writes:


 On 26/05/12 20:00, Orlando López D. wrote:

 I configured emacs org-mode on a Mac, working properly, having my org
 files and MobileOrg file within my DropBox folder ( ~/DropBox/ ).

 Now, I will like to get my emacs setup working properly on my Windows
 box. I have been able to get it working in terms of reading my .emacs
 file and emacs.d folder, shared through simlink config.

 Everything seems to be working properly, except that when I  want to
 execute org-mobile-pull or org-mobile-push on Windows, I get the
 following error: Variable `org-mobile-directory` must point to an
 existing directory 

 The problem seems to be that emacs isn't configured to read or point to
 the org-mobile directory , per the paths set in .emacs (eg. =
 ~/DropBox/ ...).


 Running on Linux I found I needed the following in my .emacs:

 (setq org-directory ~/dropbox/org/org_files)
 (setq org-mobile-directory ~/dropbox/MobileOrg)
 (setq org-mobile-inbox-for-pull
 ~/dropbox/org/org_files/tasks/org_inbox.org)

 Have you got all these set? Somewhere there is a possible bug where a
 misleading error message gets displayed referring to
 org-mobile-directory, when it means org-directory. I keep meaning to try
 and track it down.

 Ian.




 Ian, thanks for your e-mail.

 I have the following configuration, which doesn´t seems to defer in
 concept with
 yours:

 ;; Set to the location of your Org files on your local system
 (setq org-directory ~/DropBox/org)
 ;; Set to the name of the file where new notes will be stored
 (setq org-mobile-inbox-for-pull ~/DropBox/org/flagged.org)
 ;; Set toyour Dropbox root directory/MobileOrg.
 (setq org-mobile-directory ~/Dropbox/MobileOrg)

 Which could be the reason why Windows isn´t locating the path to the
 existing
 directory? Do I need to have any specific configuration on .emacs for Mac
 and
 for Windows?


 Orlando,

 I haven't used emacs on Windows for a long time. However, I don't know if
 Windows understands the concept of ~/, unless there is some emacs
 configuration that allows this. Have you tried setting the paths explicitly
 e.g. (setq org-directory C:/DropBox/org)

 Ian.

Re: [O] date added into logbook?

[Jonathan Leech-Pepin]

Hello,

I'm not sure that you can automatically include the note into a
:LOGBOOK: drawer, however if you're mostly/only working from capture
templates you could add a property for CREATED and have it
automatically fill with an inactive timestamp.

#+begin_src emacs-lisp
  (x
   Example capture
   entry
   (file+headline ~/org/todo.org Example)
   * [headline info]\n:PROPERTIES:\n:CREATED: %U\n:END: [body]
   :empty-lines 1)
#+end_src

It isn't quite the same as having it in the logbook, but it does
provide the information when you look for it.

Regards,

Jonathan

On Mon, May 28, 2012 at 6:51 PM, John Hendy jw.he...@gmail.com wrote:
 On Mon, May 28, 2012 at 4:58 PM, Michael C Gilbert m...@gilbert.org wrote:
 On May 28, 2012, at 12:56 PM, John Hendy wrote:

 On Mon, May 28, 2012 at 2:01 PM, Michael Gilbert m...@gilbert.org wrote:

 I have a desire to better track the history of notes and tasks, as they 
 get created, refiled, etc. This involves several elements, but one of them 
 involves a piece that I've wanted for a while: a way to keep the data that 
 is lost when I refile an item from my default date-tree file — the date 
 the item was created/added.

 Perhaps there is some obvious (but mysterious to me) variable I can set 
 for this, but I haven't found it. What I want is to be able to have a 
 string similar to the others added to the logbook (like  - Refiled on 
 [2012-05-28 Mon 11:33]), but for the date/time the item first appeared.

 Bernt Hansen does this (I think this is what you're looking for). Can this 
 help?
 -- http://doc.norang.ca/org-mode.html#sec-15-21


 Thank you! There it is, on the web, 80% of what I was looking for (of 
 course). This certainly has the same intent. It does not add any metadata 
 (such as a prefix  - Added on ), but the documentation for 
 org-insert-time-stamp makes it obvious how to do that. What eludes me is how 
 to make it obey the org-clock-into-drawer setting. I'm assuming it doesn't.

 — Michael



 Yes, I'm not sure about that either... I wonder if looking at the code
 for what makes todo state changes and properties log into :LOGBOOK:
 might help? I don't know any elisp to make sense of that. Perhaps
 Bernt will see this and illuminate us both?

 John