Re: [O] Patch for testing `org-open-at-point'
Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien writes: Achim Gratz strom...@nexgo.de writes: Shouldn't the test check that the desired target is actually reached? That would be too complicated. Checking that `org-open-at-point' does not throw an error is enough IMO. I don't think so. Implemented a check for that in 8e72c8fcfa. Okay, thanks. I pushed a small update, separating tests where we test that `org-open-at-point' correctly opens the link at point, and tests where we only tests that it correctly runs in a specific context. -- Bastien
Re: [O] How to find the headline matching a string
Eric Abrahamsen e...@ericabrahamsen.net writes: Thorsten Jolitz tjol...@gmail.com writes: Chris Poole li...@chrispoole.com writes: Eric Abrahamsen: the `org-map-entries' function can be given a scope of 'agenda That worked perfectly, thanks. Here's what I ended up with: (org-map-entries (lambda () (when (equal title (org-get-heading t t)) (org-entry-put (point) TODO DONE))) tag 'agenda) As much as I like the powerful `org-map-entries', I wonder if it will coexist with `org-element-map' in the future, since it does not use the new parser. Whats the recommendation here? Should one rather use ,--- | (org-element-map (org-element-parse-buffer) 'headline (lambda () ...)) `--- nowadays, or do both functions serve different purposes, or is it just a matter of taste? Interesting! I wasn't even aware of org-element-map, thanks for that. Obviously I don't know the answer to your question, but they do seem to do very similar things. On the other hand, `org-element-map' won't do multiple files, and if you want to restrict to certain elements you have to do the matching logic yourself (as opposed to `org-map-entries's agenda-style search string). I'd be curious, too, to hear if `org-map-entries' is going to get EOL'd at some point. I suppose it's safe so long as `org-scan-tags' remains the heart of the agenda process. Here's my stab at two roughly equivalent functions, one using org-element, the other older function. Just for the hell of it I tried using benchmark to profile them, but have no idea if the results mean much of anything. Most importantly, I don't really know if `org-element-parse-buffer' ends up using the cache or not -- I assume not. (defun my-find-title-element-map (title) (interactive sTitle: ) (let ((files (org-agenda-files)) found) (dolist (f files) (with-current-buffer (org-get-agenda-file-buffer f) (org-element-map (org-element-parse-buffer 'headline) 'headline (lambda (hl) (when (string= title (org-element-property :title hl)) (push (move-marker (make-marker) (org-element-property :begin hl)) found)) found)) (defun my-find-title-entries-map (title) (interactive sTitle: ) (let (found) (org-map-entries (lambda () (when (string= title (org-get-heading t t)) (push (move-marker (make-marker) (line-beginning-position)) found))) nil 'agenda) found)) (benchmark-run 100 (my-find-title-element-map Unique Heading Text)) = (164.576821235 142 23.892782392000186) (benchmark-run 100 (my-find-title-entries-map Unique Heading Text)) = (58.111630133 36 6.04777874516) This is interesting too - and a bit surprising. On my machine, the org-element based function takes almost 4 times as long as the org-map-entries based function: #+BEGIN_SRC emacs-lisp (defun my-find-title-element-map (title) (interactive sTitle: ) (let ((files (org-agenda-files)) found) (dolist (f files) (with-current-buffer (org-get-agenda-file-buffer f) (org-element-map (org-element-parse-buffer 'headline) 'headline (lambda (hl) (when (string= title (org-element-property :title hl)) (push (move-marker (make-marker) (org-element-property :begin hl)) found)) found)) #+END_SRC #+results: : my-find-title-element-map #+BEGIN_SRC emacs-lisp (defun my-find-title-entries-map (title) (interactive sTitle: ) (let (found) (org-map-entries (lambda () (when (string= title (org-get-heading t t)) (push (move-marker (make-marker) (line-beginning-position)) found))) nil 'agenda) found)) #+END_SRC #+results: : my-find-title-entries-map #+BEGIN_SRC emacs-lisp :results raw (benchmark-run 30 (my-find-title-element-map Unique Heading Text)) #+END_SRC #+results: (160.439753043 735 76.66140414599985) # = (164.576821235 142 23.892782392000186) #+BEGIN_SRC emacs-lisp :results raw (benchmark-run 30 (my-find-title-entries-map Unique Heading Text)) #+END_SRC #+results: (37.97359562205 123 12.137436705999733) # = (58.111630133 36 6.04777874516) -- cheers, Thorsten
Re: [O] Tests do not work
2014-06-02 20:17 GMT+02:00 Achim Gratz strom...@nexgo.de: Bastien writes: I'd rather add the tests to the Org archives. Done. I just downloaded again from: http://orgmode.org/ But get the same error as before. -- Cecil Westerhof
Re: [O] Tests do not work
Cecil Westerhof cldwester...@gmail.com writes: I just downloaded again from: http://orgmode.org/ But get the same error as before. As the website says, the tarballs that you download from http://orgmode.org are built from the latest stable version, which is currently 8.2.6. Achim fixed this for the next stable version, which is not released. -- Bastien
Re: [O] org-contacts development
Hi Daimrod,
On 2014-05-29, Daimrod wrote:
Hmm, I kinda like this. It seems a bit verbose but it's better than
having multiple values per properties (IMHO).
Though, if we adopt this scheme, we would need to add some helper
bindings/functions so that we don't have to fill this by hands.
I'm using yasnippets and have snippets for organizations, job-related
contacts and private contacts.
I have attached them.
C-c C-x p helps to fill in optional properties.
I have all my contacts in one buffer with the following settings
#+BEGIN_SRC org
* Buffer settings
#+STARTUP: overview
#+STARTUP: hidestars
#+STARTUP: indent
#+TAGS: ADMIN(i) CHEF(f) EINKAUF(k) PRIVAT(t) SEKRETARIAT(s)
#+TAGS: AUTO(u) BROADCASTER(b) DAB(d) DVB(v) EMPFÄNGER(m) HOCHSCHULE(h)
NETZBETREIBER(n) SYSTEM(y) B2B B2C REG
#+TAGS: MAIL(l) PRESSE(e) KUNDE COMPETITOR
#+TAGS: ABI CI FAMILIE FREUNDE SCHULE TAICHI TURNEN
#+SEQ_TODO: TODO(t) NEXT(n) WAITING(w) | DONE(d) CANCELLED(c)
#+PROPERTY: Contact_Type_ALL individual organization
#+PROPERTY: Language_ALL de en ru
#+PROPERTY: Phone_1_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_2_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_3_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_4_Type_ALL Work Home Fax Mobile
#+PROPERTY: Address_1_Type_ALL Work Home Post
#+PROPERTY: Address_2_Type_ALL Work Home Post
#+PROPERTY: Address_3_Type_ALL Work Home Post
#+PROPERTY: Website_1_Type_ALL Work Home
#+PROPERTY: Website_2_Type_ALL Work Home
#+END_SRC
Other user defined properties can be added and mapped to the appropriate
user defined keys during export.
I'm not sure to understand what you mean. Could you give more details
and maybe an example?
Actually, my statement was trivial. Orgmode allows to define and add
every kind of additional properties. What I wanted to say was that it
is possible to export those additional properties to Google Contacts as
well.
I have for instance the property :Language: that is not part of the
Google API. I use it to store the preferred language of correspondence
for my job-related contacts for mailing actions.
Google Contacts accepts such fields in the CSV file to import and
creates user defined fields from them.
Please note that org-collector tries to convert property values from
strings into numbers if possible. For postal codes with leading Zeros
this can lead to unexpected results. I did not find any other way to
solve this problem than to add a national code like in the following
example
:Address_1_Code: 01169
would lead to 1169 in the propview table.
so I replaced it with
:Address_1_Code: DE-01169
What is `org-collector' and when does it happen?
From the Orgmode manual:
An alternative way to capture and process property values into a table
is provided by Eric Schulte's org-collector.el which is a contributed
package. It provides a general API to collect properties from entries
in a certain scope, and arbitrary Lisp expressions to process these
values before inserting them into a table or a dynamic block.
I'm using org-collector to create a table that can be exported to CSV
for import into Google Contacts (and maybe other contact managers).
I've done a quick test and the 0 appears in `org-contacts-db'.
Yes, everything is fine with org-contacts. The problem comes only from
org-collector. The reason is org-collector's feature to allow Lisp
expressions to process property values. Therefore it uses the function
`org-babel-read' that detects Lisp expressions and converts strings into
numbers.
So this remark is only relevant for those who want to follow my track with the
org-collector export.
--
Michael Strey
www.strey.biz
#name : Contact Individual
#key : contact
#contributor : Michael Strey [EMAIL PROTECTED]
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
${1:surname}, ${2:name}
:LOGBOOK:
- Contact added: [`(org-read-date nil nil +0d)`]
:END:
:PROPERTIES:
:Contact_Type: individual
:Organization_1_Type: company
:Organization_1_Value: ${3:organisation}
:Organization_1_Department: ${4:devision}
:Organization_1_Title: ${5:title}
:FN: $2 $1
:Given_Name: $2
:Family_Name: $1
:Nickname: $19 $1
:Address_1_Type: Work
:Address_1_Street: ${6:adr1}
:Address_1_Box: ${7:adr2}
:Address_1_Extension: ${8:adr3}
:Address_1_City: ${9:city}
:Address_1_Region: ${10:state}
:Address_1_Code: ${11:zip_code}
:Address_1_Country: ${12:country}
:Email_1_Type: Work
:Email_1_Value: ${13:company_email}
:Phone_1_Type: Work
:Phone_1_Value: ${14:tel}
:Phone_2_Type: Mobile
:Phone_2_Value: ${15:mobile}
:Phone_3_Type: Fax
:Phone_3_Value: ${16:fax}
:Website_1_Type: Work
:Website_1_Value: http://$17
:Language: $18
:END:
$0
#name : Contact Individual (private)
#key : privat
#contributor : Michael Strey [EMAIL PROTECTED]
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
${1:surname}, ${2:name} :NEW:
:LOGBOOK:
- Contact added: [`(org-read-date nil nil +0d)`]
:END:
:PROPERTIES:
:Contact_Type: individual
Re: [O] Tests do not work
2014-06-03 12:11 GMT+02:00 Bastien b...@gnu.org: Cecil Westerhof cldwester...@gmail.com writes: I just downloaded again from: http://orgmode.org/ But get the same error as before. As the website says, the tarballs that you download from http://orgmode.org are built from the latest stable version, which is currently 8.2.6. Achim fixed this for the next stable version, which is not released. I interpreted: I'd rather add the tests to the Org archives. That they where added to the current one. But no problem: I can wait till the next release. :-) -- Cecil Westerhof
[O] org-agenda-mode: Symbol's value as variable is void: org-agenda-archives-mode
Hi List, after updating yesterday to #+begin_src emacs-lisp (call-interactively 'org-version) #+end_src #+results: : Org-mode version 8.2.6 (release_8.2.6-1123-g024a05 @ /usr/share/emacs/24.3/lisp/org/lisp/) I got this error when opening the agenda today: ,-- | org-agenda-mode: Symbol's value as variable is void: org-agenda-archives-mode `-- A quick google search led to a solution from this [[http://irreal.org/blog/?p=2030][Blog]] entry posted on 2013-08-02: Put this in init.el ,- | (setq org-agenda-archives-mode nil) | (setq org-agenda-skip-comment-trees nil) | (setq org-agenda-skip-function nil) `- Is this a bug/regression or a personnal setup thing? -- cheers, Thorsten
Re: [O] org-agenda-mode: Symbol's value as variable is void: org-agenda-archives-mode
Hi Thorsten, Thorsten Jolitz tjol...@gmail.com writes: Is this a bug/regression or a personnal setup thing? Probably something in your setup. Can you try emacs -l ~/minimal.el with minimal.el containing something like (add-to-list 'load-path ~/install/git/org-mode/lisp/) (require 'org) then call M-x org-agenda RET ? -- Bastien
Re: [O] how to use :options-alist in org-export-define-derived-backend ?
Hi Nicolas, Nicolas Richard theonewiththeevill...@yahoo.fr writes: I'm trying to play with the exporter but I'd like my back-end to have no toc by default. I tried (org-export-define-derived-backend 'mytest 'html :translate-alist ;; don't use the template, concentrate on the toc. (list (cons 'template (lambda (a _) a))) :options-alist '((:with-toc nil toc nil))) IIUC, the last nil up there should be the default value for :with-toc. I used this in contrib/lisp/ox-rss.el :options-alist '((:with-toc nil nil nil) ;; Never include HTML's toc with `nil' instead of toc. Perhaps some hint lies down here (like toc indicating the exporter should rely on the buffer-local value of `org-export-with-toc'?) but I'm not really sure, I hope Nicolas can clarify. -- Bastien
Re: [O] how to use :options-alist in org-export-define-derived-backend ?
Hello, Nicolas Richard theonewiththeevill...@yahoo.fr writes: I'm trying to play with the exporter but I'd like my back-end to have no toc by default. I tried (org-export-define-derived-backend 'mytest 'html :translate-alist ;; don't use the template, concentrate on the toc. (list (cons 'template (lambda (a _) a))) :options-alist '((:with-toc nil toc nil))) IIUC, the last nil up there should be the default value for :with-toc. Unfortunately, exporting like this: (with-temp-buffer (insert * foo\n** bar\nsome content) (org-export-to-buffer 'mytest *test*) (pop-to-buffer *test*)) will show a table of contents. FWIW, I cannot reproduce it. Regards, -- Nicolas Goaziou
Re: [O] org-agenda-mode: Symbol's value as variable is void: org-agenda-archives-mode
Bastien b...@gnu.org writes: Hi Bastien, Thorsten Jolitz tjol...@gmail.com writes: Is this a bug/regression or a personnal setup thing? Probably something in your setup. yes, apparently, Can you try emacs -l ~/minimal.el with minimal.el containing something like (add-to-list 'load-path ~/install/git/org-mode/lisp/) (require 'org) then call M-x org-agenda RET ? because this works. Thx -- cheers, Thorsten
Re: [O] src blocks not fontified
I can only find htmlfontify in ELPA, but not htmlize. Which ELPA repository will have htmlize? Or I need to install the .el file manually. I can find the htmlize.el in the following link, but not sure it's up to date. http://www.emacswiki.org/emacs-ja/htmlize.el. Thank you. On Sun, Jun 1, 2014 at 3:46 PM, Omid omidl...@gmail.com wrote: One way is to use the package htmlize, which you can install from ELPA using M-x package-install RET htmlize http://www.emacswiki.org/emacs/Htmlize Omid Sent from my Emacs On 06/01/2014 06:40 PM, Shiyuan wrote: That solves the problem. Thanks Omid. Should this be the default setup? It seems more nature to fontify the src block than not. Also, when I export the org file to html, the src block is not fontified in the resulting html webpage. Is there another option to turn this function on? Thanks. On Sun, Jun 1, 2014 at 3:17 PM, Omid omidl...@gmail.com mailto:omidl...@gmail.com wrote: Hi Shiyuan, Add (setq org-src-fontify-natively t) to your .emacs. Omid Sent from my Emacs On 06/01/2014 06:13 PM, Shiyuan wrote: Hi, I am using Emacs 24.3 with the built-in org mode(7.9.3). The src code block is not fontified (Emacs is started with -Q option) #+BEGIN_SRC emacs-lisp (defun org-xor (a b) Exclusive or. (if a (not b) b)) #+END_SRC This is my first time to use org-mode, so I could miss some setup steps.Do I need to do any setup in my .emacs if I just use the built-in org? Thanks. Shiyuan
Re: [O] src blocks not fontified
Shiyuan gshy2...@gmail.com writes: I can only find htmlfontify in ELPA, but not htmlize. Which ELPA repository will have htmlize? Or I need to install the .el file manually. I can find the htmlize.el in the following link, but not sure it's up to date. http://www.emacswiki.org/emacs-ja/htmlize.el. htmlize.el is included in the contrib/lisp directory of org (but I'm not sure if contrib is part of the ELPA org distribution - it is available if you get org from the git repo or from the tarball). The one I have says: , | ;;; htmlize.el --- Convert buffer text and decorations to HTML. | | ;; Copyright (C) 1997-2013 Hrvoje Niksic | | ;; Author: Hrvoje Niksic hnik...@xemacs.org | ;; Keywords: hypermedia, extensions | ;; Version: 1.43 ` Nick
Re: [O] problem with org-caldav and ox-icalendar: UID property wrapping
David Engster writes: Nicolas Goaziou writes: Eric S Fraga e.fr...@ucl.ac.uk writes: I have tracked this down to org-icalendar outputing wrapped lines even for UID entries: , | BEGIN:VEVENT | DTSTAMP:20140507T114443Z | UID:0400[...]00 | 00[...]6 | DTSTART;TZID=Europe/London:20120403T06 ` AFAIU RFC 5545, all lines longer than 75 octets, including UID lines, are expected to be folded. Therefore I think ox-icalendar is right. Yes, it is. I've already rewritten that part in org-caldav, but it needs more testing. I'll push a fix in the coming days. Well, that took a bit longer, but I pushed it now... -David
Re: [O] DTD prohibited
Am Dienstag, 3. Juni 2014, 00:34:58 schrieb James Harkins: Bastien bzg at gnu.org writes: Hi Alexander, AW alexander.willand at t-online.de writes: Now, Word no longer can open the html-documents produced by orgmode. The error message is (translated from German): DTD prohibited. You may want to customize `org-html-doctype' but you probably need to digg further to know what DTD is prohibited exactly. Apparently, all of them: http://en.m.wikipedia.org/wiki/Document_Type_Definition Under Security: ~~ An XML DTD can be used to create a denial of service (DoS) attack by defining nested entities that expand exponentially, or by sending the XML parser to an external resource that never returns.[10] For this reason, .NET Framework provides a property that allows prohibiting or skipping DTD parsing, [10] and recent versions of Microsoft Office applications (Microsoft Office 2010 and higher) refuse to open XML files that contain DTD declarations. ~~ So, if org ODT export now depends on a DTD, then we'd have to say that we don't support exported files that open in MS Word. hjh Hi, thank you, I started again digging into this strange thing and the culprit seems the first line of the html-file: ?xml version=1.0 encoding=utf-8? If I remove this line, no error. And removing simply xml version=1.0 helped as well. Courious. Because of such behaviour I hate Word, but ... Source: http://stackoverflow.com/a/15816168 Regards, Alexander
Re: [O] #+INCLUDE: myfile.html html does not include /literally/; Org processes
Hello, Achim Gratz strom...@nexgo.de writes: I'm not wedded to the name, maybe export has a nicer ring to it (but that#s also been used differently in Babel, just like almost anything else you#d be able to come up with). True. What I'm talking about is the list of blocks that never can be export blocks (CENTER, QUOTE, SRC, COMMENT, EXAMPLE, VERSE). These can be flagged as errors, anything else is the responsibility of the user. On second thought, we shouldn't bother too much about it, let the user provide any keyword, and turn it into a block of the same name. So, for example, both #+include: file.html html and #+include: file.html center are valid, even though the second one makes little sense. It is close to your initial approach, minus the wrap keyword, which seems unnecessary. If you agree with this suggestion, do you volunteer to finalize it, along with the required documentation? Regards, -- Nicolas Goaziou
Re: [O] How to find the headline matching a string
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: I guess it shouldn't be too surprising -- the org element stuff is completely parsing the entire buffer on every pass. The other function probably boils down to passing a few targeted regexps over the buffer. I've sneakily cc'd Nicolas to see what he thinks. My guess is we could replace the call to org-element-parse-buffer with something that creates/accesses the cached version of the parse tree, and things would go much more swiftly. I didn't look closely into the issue, but I think the main reason is that Element parses headlines thoroughly, including all properties, scheduled keywords, which is not, by default, the case for `org-map-entries'. For most use-cases, you don't need the parser for headlines, as their grammar is context free. IOW, `org-element-parse-buffer' doesn't predate `org-map-entries'. Interesting, thanks! I think at first we were unsure if org-map-entries was going to stay around in the long term, but it sounds like it's not going anywhere. E
