Re: [O] bug#32722: bug#32722: bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?
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 ?
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
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?
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?
Hello Nicolas On 17 December 2017 at 05:34, Nicolas Goaziouwrote: > 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
On 18 April 2017 at 09:26, Eric S Fragawrote: > 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
Hi, On May 18, 2016 5:21:06 AM EDT, Rasmuswrote: >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
On November 3, 2015 4:31:11 PM EST, Achim Gratzwrote: >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
Hello, On 24 September 2015 at 18:01, Rasmuswrote: > 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?
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
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
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
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?
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'
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?
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`
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
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
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?
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
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
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'?
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
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
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
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?
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
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
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 ?
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
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?
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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?
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?
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
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
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
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
(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
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
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
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
-- 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
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 @@
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'
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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?
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?
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
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?
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
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
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
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
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)
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
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?
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