Re: [O] [babel] Code for simple set-operations on two tables. Asking for some input.
Am 27.12.2011 21:53, schrieb Eric Schulte: Marc-Oliver Ihmmarc-oliver@online.de writes: Hello, Please find attached the elisp-file and a tutorial (as an org-file) for org-babel-table-proc. It provides some simple set-operations (mostly merge and intersect), which treat org-mode tables as sets. An example for merging two tables would be: #+name: lower | 2 | b | | 4 | d | | 5 | e | | 6 | h | #+name: upper | 1 | A | | 3 | C | | 4 | D | | 10 | J | | 2 | B | #+begin_src emacs-lisp :var t1=lower :var t2=upper (babel-table-proc-merge t1 t2) #+end_src #+results: | 1 | | A | | 2 | b | B | | 3 | | C | | 4 | d | D | | 5 | e | | | 6 | h | | | 10 | | J | which merges the two input tables lower and upper into a single table, even, if they do not have all keys (from the first column) in common. In general this merges information from two different sources without loosing anything. The package org-babel-table-proc provides these and a few other operations, but definitely still needs some debugging and polishing. However, before finishing this work, I would like to ask, if something like this is already present in babel or the library of babel ? Nothing like this is currently available in the library of Babel. I do think that such a library of indexed set operations would be a useful addition to the library. As for packaging, although it may be more comfortable to develop these functions in the manner you are currently using (with side-by-side .el and .org files), when it comes time to add these code blocks to the library of babel, I would recommend *combining* the elisp source and the explanatory prose as a single new subtree in the existing org-babel-library-of-babel.org file. Rather than exposing these functions as elisp functions they could be exposed as Babel code blocks, e.g., #+begin_src emacs-lisp :var t1=lower :var t2=upper (babel-table-proc-merge t1 t2) #+end_src would instead become #+call: proc-merge(lower, upper) Also, I am not sure, which prefix to use for packages and functions; is org-babel-table-proc the right name or can it be shortened to ob-table-proc. If you package these as code blocks in the library of babel then there is no issue of prefixing, just pick meaningful names for the code blocks and don't define any global elisp functions. Any input would be very welcome ! I hope the above helps, please let me know if I have been unclear or if you have any other questions. I look forward to your patch! Cheers, With kind regards, Marc-Oliver Ihm Hi Eric, Thanx, that was exactly the input I was looking for. Now I have something nice to code over the vacations :-) I will try to merge it all into the existing library without using global functions and come back with a patch ... with kind regards, Marc-Oliver Ihm
Re: [O] Orthogonality of blocks
On 27/12/11 21:12, Christian Moe wrote: will do it in HTML. Full example follows below. I'll leave LaTeX to those in the know... Thanks. This was the best solution for me. I quote because the abstraction boundary between how it's rendered and what I want to be rendered is getting fuliginous. It would be much better imo to have blocks of first-class, and functions of higher-order on those blocks, so one could say (side-by-side block1 block2) and the side-by-side procedure would deal with the different format nuances. The idea is similar to that of the Henderson Escher examples in SICP[1], where you have painters and functions that combine painters in interesting ways. Might be fun to investigate how far that can go with blocks in org. @Jambunathan: Your examples render the blocks with sizes proportional to the contained text, rather than aligning as a table. I find that aesthetically displeasing :-( Thanks all for the help. Charles. [1] http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html#%_sec_2.2.4
Re: [O] Bugs/features of accumulating property values when used with entries (concretely: in org-contacts)
Hi Seb, thanks for your help! 2011-12-26 15:50 Sebastien Vauban: Christoph LANGEch.la...@jacobs-university.de writes: 2. accumulation doesn't work within the same entry; details follow: So when I changed the above contact entry to * Contact Name :PROPERTIES: :EMAIL:f...@bar.org :EMAIL+: b...@baz.org :END: I would have expected (org-entry-get (point) EMAIL t) to evaluate to, well, at least f...@bar.org b...@baz.org (and in some later version of org-mode maybe to a two-item list, for even easier automated processing). But I got the following unexpected results, which indicate that accumulation is not yet supported in this context (well, if it was ever _intended_…): … AFAIK the `+' is only supported at this stage for the `var' property: you can't take any property and add a `+' to transform it in an accumulative property. Whether this should be restricted by default or open by default, I have no opinion at this stage. If it is intended to be limited to the var property, then at least the documentation (Property syntax) needs fixing, as it states generally: If you want to add to the value of an existing property, append a `+' to the property name. But thanks a lot for pointing this out: I know, however, multivalued properties are sort of already well supported. See http://orgmode.org/manual/Using-the-property-API.html for more info. Cheers, Christoph -- Christoph Lange, http://www.facebook.com/ch.lange, Skype duke4701
Re: [O] Bugs/features of accumulating property values when used with entries (concretely: in org-contacts)
Christoph LANGE ch.la...@jacobs-university.de writes: Hi Seb, thanks for your help! 2011-12-26 15:50 Sebastien Vauban: Christoph LANGEch.la...@jacobs-university.de writes: 2. accumulation doesn't work within the same entry; details follow: So when I changed the above contact entry to * Contact Name :PROPERTIES: :EMAIL:f...@bar.org :EMAIL+: b...@baz.org :END: I would have expected (org-entry-get (point) EMAIL t) to evaluate to, well, at least f...@bar.org b...@baz.org (and in some later version of org-mode maybe to a two-item list, for even easier automated processing). But I got the following unexpected results, which indicate that accumulation is not yet supported in this context (well, if it was ever _intended_…): See the attached file for an example of working property inheritance. #+Property: EMAIL f...@bar.org * Contact Name :PROPERTIES: :EMAIL+: b...@baz.org :END: #+begin_src emacs-lisp (org-entry-get (point) email 'inherit) #+end_src #+results: : f...@bar.org b...@baz.org * Contact Name :PROPERTIES: :FOO:1 :FOO+: 2 :END: #+begin_src emacs-lisp (org-entry-get (point) FOO 'inherit) #+end_src #+results: : 1 While it is not possible to accumulate two properties from within the same block, property accumulation does successfully add to the inherited values of variables. I don't know if it should be possible to accumulate properties within the same property block. I would imagine so, in which case the behavior should be considered a bug. … AFAIK the `+' is only supported at this stage for the `var' property: you can't take any property and add a `+' to FALSE, the var property is in no way special when it comes to property inheritance. All properties are treated equally. Best, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bugs/features of accumulating property values when used with entries (concretely: in org-contacts)
Christoph LANGE ch.la...@jacobs-university.de writes: Hi Seb, thanks for your help! 2011-12-26 15:50 Sebastien Vauban: Christoph LANGEch.la...@jacobs-university.de writes: 2. accumulation doesn't work within the same entry; details follow: So when I changed the above contact entry to * Contact Name :PROPERTIES: :EMAIL:f...@bar.org :EMAIL+: b...@baz.org :END: I would have expected (org-entry-get (point) EMAIL t) to evaluate to, well, at least f...@bar.org b...@baz.org (and in some later version of org-mode maybe to a two-item list, for even easier automated processing). But I got the following unexpected results, which indicate that accumulation is not yet supported in this context (well, if it was ever _intended_…): … AFAIK the `+' is only supported at this stage for the `var' property: you can't take any property and add a `+' to transform it in an accumulative property. Whether this should be restricted by default or open by default, I have no opinion at this stage. If it is intended to be limited to the var property, then at least the documentation (Property syntax) needs fixing, as it states generally: If you want to add to the value of an existing property, append a `+' to the property name. But thanks a lot for pointing this out: I know, however, multivalued properties are sort of already well supported. See http://orgmode.org/manual/Using-the-property-API.html for more info. Cheers, Christoph Aloha Christoph and Seb, The following example shows that the accumulative property isn't restricted to var/var+. * Accumulative properties syntax #+property: not-var 0 :PROPERTIES: :not-var+: 3 :END: #+begin_src emacs-lisp (org-entry-get (point) not-var t) #+end_src #+results: : 0 3 To run the example, you'll need to refresh the local setup by C-c C-c on the #+property: not-var 0 line, then execute the emacs-lisp source block. I didn't follow this thread closely, so I don't know if my experience is useful, but when I briefly studied the accumulative property syntax I tripped up on two things: 1) I often forgot to renew the local setup so that changes in #+property: lines would take effect; and 2) I tried to add more than one instance of a property in a drawer, which isn't allowed. hth, Tom -- Thomas S. Dye http://www.tsdye.com
[O] [PATCH] integration with bbdb 3.0
Hi Bastien, The following patch fixes linking bbdb 3.0 records. Let me know if the patch needs improvement. Take care, Ivan Kanis diff --git a/emacs/org/org-bbdb.el b/emacs/org/org-bbdb.el index 61f8258..ddb7e4a 100644 --- a/emacs/org/org-bbdb.el +++ b/emacs/org/org-bbdb.el @@ -118,6 +118,9 @@ (defvar date) ;; dynamically scoped from Org +;; Support for version 2.35 +(defvar org-bbdb-old (fboundp 'bbdb-record-get-field-internal)) + ;; Customization (defgroup org-bbdb-anniversaries nil @@ -195,8 +198,11 @@ date year). Store a link to a BBDB database entry. (when (eq major-mode 'bbdb-mode) ;; This is BBDB, we make this link! -(let* ((name (bbdb-record-name (bbdb-current-record))) - (company (bbdb-record-getprop (bbdb-current-record) 'company)) +(let* ((rec (bbdb-current-record)) + (name (bbdb-record-name rec)) + (company (if org-bbdb-old +(bbdb-record-getprop rec 'company) + (car (bbdb-record-get-field rec 'organization (link (org-make-link bbdb: name))) (org-store-link-props :type bbdb :name name :company company :link link :description name) @@ -218,24 +224,49 @@ italicized, in all other cases it is left unchanged. (require 'bbdb) (let ((inhibit-redisplay (not debug-on-error)) (bbdb-electric-p nil)) -(catch 'exit - ;; Exact match on name - (bbdb-name (concat \\` name \\') nil) - (if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) - ;; Exact match on name - (bbdb-company (concat \\` name \\') nil) - (if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) - ;; Partial match on name - (bbdb-name name nil) - (if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) - ;; Partial match on company - (bbdb-company name nil) - (if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) - ;; General match including network address and notes - (bbdb name nil) - (when (= 0 (buffer-size (get-buffer *BBDB*))) - (delete-window (get-buffer-window *BBDB*)) - (error No matching BBDB record) +(if org-bbdb-old +(org-bbdb-open-old) + (org-bbdb-open-new + +(defun org-bbdb-open-old () + (catch 'exit +;; Exact match on name +(bbdb-name (concat \\` name \\') nil) +(if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) +;; Exact match on name +(bbdb-company (concat \\` name \\') nil) +(if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) +;; Partial match on name +(bbdb-name name nil) +(if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) +;; Partial match on company +(bbdb-company name nil) +(if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) +;; General match including network address and notes +(bbdb name nil) +(when (= 0 (buffer-size (get-buffer *BBDB*))) + (delete-window (get-buffer-window *BBDB*)) + (error No matching BBDB record + +(defun org-bbdb-open-new () + (catch 'exit +;; Exact match on name +(bbdb-search-name (concat \\` name \\') nil) +(if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) +;; Exact match on name +(bbdb-search-organization (concat \\` name \\') nil) +(if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) +;; Partial match on name +(bbdb-search-name name nil) +(if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) +;; Partial match on company +(bbdb-search-organization name nil) +(if ( 0 (buffer-size (get-buffer *BBDB*))) (throw 'exit nil)) +;; General match including network address and notes +(bbdb name nil) +(when (= 0 (buffer-size (get-buffer *BBDB*))) + (delete-window (get-buffer-window *BBDB*)) + (error No matching BBDB record (defun org-bbdb-anniv-extract-date (time-str) Convert -MM-DD to (month date year).
Re: [O] Org-drill doesn't work...
JK == Joost Kremers joostkrem...@fastmail.fm writes: JK however, trying to run org-drill the next day, i got the JK following message: JK #+BEGIN_EXAMPLE JK 0 items reviewed. Session duration 0:00:00. JK Recall of reviewed items: JK Excellent (5): 0% | Near miss (2):0% JK Good (4):0% | Failure (1): 0% JK Hard (3):0% | Abject failure (0): 0% JK You successfully recalled 0% of reviewed items (quality 2) JK 0/1 items still await review (0 failed, 0 overdue, 0 new, 0 young, 0 old). JK Tomorrow, 0 more items will become due for review. JK Session finished. Press a key to continue... JK #+END_EXAMPLE JK i wasn't prompted for any new items and the message tomorrow, 0 JK more items will become due for review worries me. JK also, running org-drill-again gives me the same message. This is all right. You've just learned all the items and there is nothing to learn/repeat now. Nor tomorrow, there is minimum amount of 4 days by default before you are prompted for the same item again (I believe you can customize the interval with org-drill-sm5-initial-interval). In the meantime you can add and train new entries. :-)
[O] Emacs macros and capture
Hi, I'm seeing some weird behavior with my capture template setup. I have the following in my capture templates: (r Reply entry (file+headline ~/org/gtd/gtd.org Reply) * TODO %:subject :@respond:@email: \n %u\n %i\n %a\nFrom: %:from\nID:%:message-id\n %? :immediate-finish t) What this template does is create a new headline under Reply in my gtd.org file with the subject as the title of the headline. It will then place a link to the email as well as some other metadata. Here's an example: *** TODO LibraryThing: State of the Thing - December 2011:@review:@email: [2011-12-28 Wed] [[notmuch:id:201112151815.pbfiflxh021...@athena.librarything.com][Email from jer...@librarything.com: LibraryThing: State of the Thi]] From: jer...@librarything.com ID:201112151815.pbfiflxh021...@athena.librarything.com end example That works fine. Now if I record the keystrokes as a macro, and then execute the macro, here is what I get (same email as above): *** TODO LibraryThing: State of the Thing - December 2011:@review:@email: [2011-12-28 Wed] From: jer...@librarything.com ID:201112151815.pbfiflxh021...@athena.librarything.com end example As you can see, it recorded everything _but_ the link (the most important part). Any idea why this happens? Thanks.
[O] Enhancing table cell alignments and commenting columns (was Re: Orthogonality of blocks)
Jambunathan K kjambunat...@gmail.com writes: Charles Turner chtu...@gmail.com writes: @Jambunathan: Your examples render the blocks with sizes proportional to the contained text, rather than aligning as a table. I find that aesthetically displeasing :-( I am unable to understand what sizes proportional to the contained text means. What viewer are you using? I am using a fairly recent version of LibreOffice (v3.4.4) and I see that the positions of the blocks are a bit staggered (See portions marked red in the attached png) Furthermore, the srcline where the cursor is - marked with an ellipse - uses OrgSrcBlockLastLine style. If the style were modified to OrgSrcBlock style, I see that the above staggering gets less accentuated. A plausible explanation for this behaviour is that the space below paragraph introduced by OrgSrcBlockLastLine spills over to the next paragraph which is in the second table column. One of the reasons that the staggering persists is because of the change in space settings between Text_20_body and OrgSrcBlock styles (Note that the Say Hello in ... lines and the src block lines use different fonts and font sizes and different paragraph styles) AFAIK, there is nothing amiss with the XML that the ODT exporter dumps and I am inclined to think that the issue is with LibreOffice rendering engine. I am wrong, the issue is not with the LibreOffice but with my memory. The srcblocks are actually aligned centrally (along the vertical axis) within the table cell. Since the two blocks are of different sizes/lengths the top border gets staggered. Changing the alignment to top will fix the issue. #+begin_src nxml :see OrgOdtContentTemplate.xml style:style style:name=OrgTblCell style:family=table-cell @@@ style:table-cell-properties style:vertical-align=middle fo:padding=0.159cm fo:border-top=none fo:border-bottom=none fo:border-left=none fo:border-right=none/ /style:style #+end_src There colcookies that specify how a table column has to be aligned. Currently there are specifiers only for left and right alignment. , (info (org) Column width and alignment) |If you would like to overrule the automatic alignment of number-rich | columns to the right and of string-rich column to the left, you can use | `r', `c'(2) or `l' in a similar fashion. You may also combine | alignment and field width like this: `l10'. ` I think it would be useful to specify a top alignment specifier. There is also a recent interest in commenting out certain Org-table columns [1]. I think the colcookie lines could be enhnaced to also support t and / characters. IMNSHO, using #+ATTR_ODT: lines for commenting out columns will not only be cumbersome but also error-prone. ps: I am not much concerned xhtml exporter as it is mostly a museum piece cherished just by me. Footnotes: [1] http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00691.html --
Re: [O] Enhancing table cell alignments and commenting columns (was Re: Orthogonality of blocks)
I think the colcookie lines could be enhnaced to also support t and / characters. IMNSHO, using #+ATTR_ODT: lines for commenting out columns will not only be cumbersome but also error-prone. A random thought: I think there will be more flexibility if the colcookies characters - l and r - were actually style strings (of length 1). The backend can use their own discretion on how they apply these styles. There was some interest to mark certain columns specially - for example, mark automatically computed derived columns specially (both in Org and may be in the different backends). The colcookie could line could be put to some use here. (Question: Is there a way to fontify a rectangle in Emacs?) On a related note: From ODT perspective and taking a cue from the way LibreOffice does autoformatting of tables, I was thinking of introducing template tables whose only job is to specify the styles to be associated with each of the different categories of table cells. OpenDocument talks of following types of columns and LibreOffice's autoformatting is much richer and recognizes, I believe, as much as 16 categories of table cells. , C-h v org-export-odt-table-styles | TABLE-CELL-TYPE := FirstRow | LastColumn | | FirstRow | LastRow| | EvenRow| OddRow | | EvenColumn | OddColumn | | ` #+ATTR_ODT: template-table | red | green | yellow | |-+---+| | | || ps: I don't have time to implement the above features. I am just capturing my thoughts so that it is archived. --
Re: [O] Orthogonality of blocks
If I look at the figures in the link provided, I am reminded of table.el tables. Put your different src blocks in table.el tables, this way even if you don't get fontification of src blocks atleast you will have a side-by-side output with both html and latex backends. Charles Turner chtu...@gmail.com writes: On 27/12/11 21:12, Christian Moe wrote: will do it in HTML. Full example follows below. I'll leave LaTeX to those in the know... Thanks. This was the best solution for me. I quote because the abstraction boundary between how it's rendered and what I want to be rendered is getting fuliginous. It would be much better imo to have blocks of first-class, and functions of higher-order on those blocks, so one could say (side-by-side block1 block2) and the side-by-side procedure would deal with the different format nuances. The idea is similar to that of the Henderson Escher examples in SICP[1], where you have painters and functions that combine painters in interesting ways. Might be fun to investigate how far that can go with blocks in org. @Jambunathan: Your examples render the blocks with sizes proportional to the contained text, rather than aligning as a table. I find that aesthetically displeasing :-( Thanks all for the help. Charles. [1] http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-15.html#%_sec_2.2.4 --
