Re: [O] direct link to mails in gmail
On Thu, Oct 20, 2011 at 4:41 AM, Torsten Wagner torsten.wag...@gmail.comwrote: Hi, I just figured out some kind of very interesting possibility. All the personal data and security feelings aside, I use a gmail account since I share it between many different computers. In my org-files, I would sometimes like to link to a particular mail e.g., for reference purpose. Today I noticed that each email in my google mail account has a unique and fixed URL. Thus, I gave it a try 1. Open your gmail account (log-in) 2. Open the mail you like to refer too. 3. Copy the URL 4. Add the URL as a link (C-c C-l) to your org-file After that, clicking on the link will open the mail directly in your standard webbrowser. If you logged out from google mail in between, you are ask to log-in first, after that select the link again. That is really nice - and I used it to link to gmail emails from rtm - but there is one thing youi should be aware of: the link is only valid, if the mail keeps the label. As an example: If I copy the link from the inbox, paste it into an org file, and *then* archive the mail, the link is, to my knowledge, not valid any more, as it contains the label in it. So: it works, but it is essential to copy either the link when the label is selected which will be permanent, or, saver, copy the url in the All Mail folder. Cheers and thanks for the tip, Rainer But it is getting even better. You are not only able to link to particular mails within org-mode, but also to google mail labels (folders) or search results. To make it even more org-mode friendly one can set-up org-capture in your webbrowser [1]. I added the following to the org-capture-templates list (g Gmail-link entry (file+headline ~/org/work.org Gmail-links) %A) Thus, pressing the assigned button in your browser and emacs will ask you what kind of link you want to add to your file. Press g for gmail and enter the description for the link (this could be done automatically, but I find it to long and not helpful). You will find the link in your capture buffer in emacs for further processing I really like it and I hope others find this useful too. Not sure about the safety issue to link to URLs within your gmail account. Maybe others can comment on this. All the best Totti [1] http://orgmode.org/worg/org-**contrib/org-protocol.htmlhttp://orgmode.org/worg/org-contrib/org-protocol.html -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] direct link to mails in gmail
On the mac, you can create links using the message-id (this is used in org-mac-message.el) - I would be surprised if GMail did not have a way to find a message with a specific id...? - Carsten On Oct 20, 2011, at 9:30 AM, Sebastien Vauban wrote: Hi, Rainer M Krug wrote: That is really nice - and I used it to link to gmail emails from rtm - but there is one thing youi should be aware of: the link is only valid, if the mail keeps the label. As an example: If I copy the link from the inbox, paste it into an org file, and *then* archive the mail, the link is, to my knowledge, not valid any more, as it contains the label in it. Sad to say it is also true with Gnus: if you move the mail from one folder to another, the link is not valid anymore... I'd dream being able to even get shareable links: be able to make a valid reference to a mail we received on a mailing list, and that this reference would be not only valid for me, but (at least) for my colleagues using Gnus as well... Best regards, Seb -- Sebastien Vauban - Carsten
Re: [O] Patch for bug in adjusting time ranges in Agenda
Never mind resubmitting, I will take a look at the patch later today. - Carsten On Oct 17, 2011, at 10:50 AM, Niels Giesen wrote: On Sun, Oct 16, 2011 at 6:43 PM, Nick Dokos nicholas.do...@hp.com wrote: Niels Giesen niels.gie...@gmail.com wrote: *bump* Has this one slipped through (as I were posting two other patches round the same date, one also having to do with date/time ranges in the agenda -- which were both accepted), or am I just impatient? I tried to check patchwork (http://patchwork.newartisans.com/project/org-mode/) but the server seems to be having problems right now. However, that's the first place to check when it comes back: if it's there, somebody will get to it sooner or later. Ok, I checked today (server is up again) and it's not there. But I've been a fool. Should've submitted as an attachment as per http://orgmode.org/worg/org-contribute.html . Should I try and resubmit? Nick On Sun, Oct 2, 2011 at 12:24 PM, Niels Giesen niels.gie...@gmail.com wrote: Hi Orgers, The discussion in the recent thread Time range end in agenda view not displayed prompted me to take a closer look at time/date ranges in the Agenda view. I noticed that the commands `org-agenda-do-date-later' and `org-agenda-do-date-earlier' do not work correctly on timestamp ranges, in that they only shift the rightmost timestamp in the range. The patch below should fix this. #+begin_src diff From 2e6b64dc8dcae0fd312729af96ab10d8d2e9d91b Mon Sep 17 00:00:00 2001 From: Niels Giesen niels.gie...@gmail.com Date: Sun, 2 Oct 2011 09:15:21 +0200 Subject: [PATCH] Fix shift-adjusting time and date ranges from within Agenda. ,* org-mode/lisp/org-agenda.el (org-agenda-date-later): Adjust both start and end timestamp for a range, and set `org-last-changed-timestamp' to a representation of the new range. --- lisp/org-agenda.el |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index b1fa5f5..e4c1053 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7517,7 +7517,13 @@ the same tree node, and the headline of the tree node in the Org-mode file. (goto-char pos) (if (not (org-at-timestamp-p)) (error Cannot find time stamp)) - (org-timestamp-change arg (or what 'day))) + (org-timestamp-change arg (or what 'day)) + (when (org-at-date-range-p) + (let ((end org-last-changed-timestamp)) + (re-search-backward org-tr-regexp-both) + (org-timestamp-change arg (or what 'day)) + (setq org-last-changed-timestamp +(concat org-last-changed-timestamp -- end) (org-agenda-show-new-time marker org-last-changed-timestamp)) (message Time stamp changed to %s org-last-changed-timestamp))) -- 1.7.2.5 #+end_src Regards, niels -- http://pft.github.com -- http://pft.github.com Alternatives: -- http://pft.github.com - Carsten
Re: [O] direct link to mails in gmail
On Thu, Oct 20, 2011 at 9:30 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi, Rainer M Krug wrote: That is really nice - and I used it to link to gmail emails from rtm - but there is one thing youi should be aware of: the link is only valid, if the mail keeps the label. As an example: If I copy the link from the inbox, paste it into an org file, and *then* archive the mail, the link is, to my knowledge, not valid any more, as it contains the label in it. Sad to say it is also true with Gnus: if you move the mail from one folder to another, the link is not valid anymore... I'd dream being able to even get shareable links: be able to make a valid reference to a mail we received on a mailing list, and that this reference would be not only valid for me, but (at least) for my colleagues using Gnus as well... Under gmail, you can open the mail under All Mail, which then is a ink independent of the label. But it would be nice, to have access to that link more easily. Cheers, Rainer Best regards, Seb -- Sebastien Vauban -- 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 (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [babel] Verbatim output from SQL command
Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Babel seems to interpret every *leading space* as *one empty column*. Normal, feature, bug? Is there some workaround to this? I thought stating scalar would really completely override any interpretation... I've just pushed up a fix which should resolve this issue. It does better things, but at least at the wrong place. oh, I forgot to insert into a temporary buffer. This should now be fixed. This works like a charm. Thanks a lot! Best regards, Seb -- Sebastien Vauban
Re: [O] direct link to mails in gmail
As a workaround I use the following setup: ;; === org link abbreviations === (setq org-link-abbrev-alist '((mail . https://mail.google.com/a/mydomain.at/#mbox/%s;) )) When I want to link to a mail message in Gmail I click twice into the address line of firefox which conveniently selects the last part of the url (like 1331c8de4ddc74ed) which is kind of a message ID. Then I go to Emacs and copy and paste this ID into my mail link. Regards,
Re: [O] direct link to mails in gmail
Rainer M Krug r.m.krug at gmail.com writes: That is really nice - and I used it to link to gmail emails from rtm - but there is one thing youi should be aware of: the link is only valid, if the mail keeps the label. As an example: If I copy the link from the inbox, paste it into an org file, and *then* archive the mail, the link is, to my knowledge, not valid any more, as it contains the label in it. So: it works, but it is essential to copy either the link when the label is selected which will be permanent, or, saver, copy the url in the All Mail folder.Cheers and thanks for the tip,Rainer Since any mail can be found under the All label by definition the simplest solution is extracting the message id from the end of the current url and then creating a new url pointing to All. This URL should always work unless the mail is deleted: https://mail.google.com/mail/?shva=1#all/msgid
Re: [O] direct link to mails in gmail
Hi Carsten, Carsten Dominik wrote: On Oct 20, 2011, at 9:30 AM, Sebastien Vauban wrote: Sad to say it is also true with Gnus: if you move the mail from one folder to another, the link is not valid anymore... I'd dream being able to even get shareable links: be able to make a valid reference to a mail we received on a mailing list, and that this reference would be not only valid for me, but (at least) for my colleagues using Gnus as well... On the mac, you can create links using the message-id (this is used in org-mac-message.el) - I would be surprised if GMail did not have a way to find a message with a specific id...? Unluckily, I wasn't speaking of GMail mails, but of mails on our company mail server (Courrier). Best regards, Seb -- Sebastien Vauban
[O] LATEX_CLASS_OPTIONS in SETUPFILE
Hi, When using #+SETUPFILE and exporting via LaTeX, the LATEX_CLASS_OPTIONS provided in the included file are ignored. With the following two files in the same directory, doing C-c C-e L (org-export to a temporary LaTeX buffer) produces a documentclass with class report (good, as expected) and options [11pt] (not as expected). Placing the LATEX_CLASS_OPTIONS line in top.org produces the expected options. I believe that the reason is that LATEX_CLASS_OPTIONS is not handled within org-infile-export-plist in org-exp.el. --- top.org --- #+TITLE: LaTeX Class Options #+SETUPFILE: include.org * Introduction Here is some text. --- end --- --- include.org --- #+LATEX_CLASS: report #+LATEX_CLASS_OPTIONS: [a4paper,10pt] ---end --- There may be similar keywords for LaTeX or other backends that are also not handled which maybe should be; this one is the one I noticed because I tried to use it. Best wishes, Christophe
[O] [babel] Expand code is failing on a #+call line
Hi Eric, * Config ** Some file to be ingested Let's say I have this code in a =my-lob.org= file: #+srcname: add-column-in-table(table=, column=, type=, nullability=) #+begin_src sql -- add column `$column' (if column does not exist yet) IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '$table' AND COLUMN_NAME = '$column') BEGIN ALTER TABLE $table ADD $column $type $nullability END #+end_src ** In .emacs ... which I ingest at Emacs startup through the lines: #+begin_src emacs-lisp (require 'ob-lob) (org-babel-lob-ingest ~/org/my-lob.org) #+end_src * Some other document ** Source params In some other document, I have a table with columns I'd like to add in a database: #+results: params | table | column | type| nullability | |-++-+-| | dossier | pfiResetDate | date| NULL| | dossier | pfiResetOprID | tinyint | NULL| | dossier | pfiResetOprNom | varchar(64) | NULL| Normally, I could call statements like this: #+call: add-column-in-table(table=params[2,0], column=params[2,1], type=params[2,2], nullability=params[2,3]) But... ** Expand code is failing =C-c C-v C-v= does generate an error: setf: Wrong type argument: consp, nil #+begin_src text Debugger entered--Lisp error: (wrong-type-argument consp nil) setcar(nil ((:cache . ) (:comments . ) (:exports . ) (:noweb . ) (:padline . ) (:results . ) (:shebang . ) (:tangle . ))) (setf (nth 2 info) (sort (org-babel-merge-params ... params) (lambda ... ...))) (let* ((info ...) (lang ...) (params ...) (body ...) (expand-cmd ...) (assignments-cmd ...) (expanded ...)) (org-edit-src-code nil expanded (concat *Org-Babel Preview ... [ lang ]*))) org-babel-expand-src-block() call-interactively(org-babel-expand-src-block nil nil) #+end_src This stays very unclear to me... ** Execute code is failing By the way, =C-c C-v C-e= returns as well an error: let: Wrong type argument: stringp, nil This is explainable: that's because the SQL =engine= is not known (not given neither in the header of the code block, neither anywhere in this file). #+begin_src text Debugger entered--Lisp error: (wrong-type-argument stringp nil) intern(nil) (let ((--cl-var-- ...)) (cond (... ...) (... ...) (... ...) (t ...))) (case (intern engine) ((quote msosql) (format osql %s -s \ \ -i %s -o %s ... ... ...)) ((quote mysql) (format mysql %s %s %s ... ... ...)) ((quote postgresql) (format psql -A -P footer=off -F \\ -f %s -o %s %s ... ... ...)) (t (error no support for the %s sql engine engine))) (let* ((result-params ...) (cmdline ...) (engine ...) (in-file ...) (out-file ...) (header-delim ) (command ...)) (with-temp-file in-file (insert ...)) (message command) (shell-command command) (if (or ... ... ... ... ...) (with-temp-buffer ...) (with-temp-buffer ... ... ...))) org-babel-execute:sql(-- add column `$column' (if column does not exist yet)\nIF NOT EXISTS (SELECT *\n FROM INFORMATION_SCHEMA.COLUMNS\n WHERE TABLE_NAME = '$table'\n AND COLUMN_NAME = '$column')\nBEGIN\nALTER TABLE $table\nADD $column $type $nullability\nEND ((:var table . dossier) (:var column . pfiResetDate) (:var type . date) (:var nullability . NULL) (:colname-names) (:rowname-names) (:result-params silent replace) (:result-type . value) (:comments . ) (:shebang . ) (:cache . no) (:padline . ) (:noweb . no) (:tangle . no) (:exports . code) (:results . silent) (:padnewline . yes) (:hlines . no) (:session . none) (:result-type . value) (:result-params replace) (:rowname-names) (:colname-names))) #+end_src Though, I guess we should have a proper manner to report that some necessary arguments are missing, instead of failing with a unclear message. ** Other weirdnesses While the variable =org-babel-library-of-babel= contains the ingested code (here, of =add-column-in-table=), the variable =org-babel-lob-files= is =nil=!? ** Speed commands Speed commands don't work on the =#+call= lines. If I press =v= or =e=, they're inserted verbatim. Can you help me understand the 1^st point of these 4? Thanks a lot!! Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Expand code is failing on a #+call line
Hi Seb, This is a minor point, but would you mind structuring your emails with an introduction of pure-prose (no embedded examples), saving the examples for the end (footnotes work well for this). I often find it disjointing to try to ingest large code example while simultaneously trying to figure out the high-level point of the email. As to this specific question... I am not sure where you are trying to expand a code block. It seems as if you are trying to expand a call line, but I do not believe that is supposed to be possible. Best -- Eric Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, * Config ** Some file to be ingested Let's say I have this code in a =my-lob.org= file: #+srcname: add-column-in-table(table=, column=, type=, nullability=) #+begin_src sql -- add column `$column' (if column does not exist yet) IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '$table' AND COLUMN_NAME = '$column') BEGIN ALTER TABLE $table ADD $column $type $nullability END #+end_src ** In .emacs ... which I ingest at Emacs startup through the lines: #+begin_src emacs-lisp (require 'ob-lob) (org-babel-lob-ingest ~/org/my-lob.org) #+end_src * Some other document ** Source params In some other document, I have a table with columns I'd like to add in a database: #+results: params | table | column | type| nullability | |-++-+-| | dossier | pfiResetDate | date| NULL| | dossier | pfiResetOprID | tinyint | NULL| | dossier | pfiResetOprNom | varchar(64) | NULL| Normally, I could call statements like this: #+call: add-column-in-table(table=params[2,0], column=params[2,1], type=params[2,2], nullability=params[2,3]) But... ** Expand code is failing =C-c C-v C-v= does generate an error: setf: Wrong type argument: consp, nil #+begin_src text Debugger entered--Lisp error: (wrong-type-argument consp nil) setcar(nil ((:cache . ) (:comments . ) (:exports . ) (:noweb . ) (:padline . ) (:results . ) (:shebang . ) (:tangle . ))) (setf (nth 2 info) (sort (org-babel-merge-params ... params) (lambda ... ...))) (let* ((info ...) (lang ...) (params ...) (body ...) (expand-cmd ...) (assignments-cmd ...) (expanded ...)) (org-edit-src-code nil expanded (concat *Org-Babel Preview ... [ lang ]*))) org-babel-expand-src-block() call-interactively(org-babel-expand-src-block nil nil) #+end_src This stays very unclear to me... ** Execute code is failing By the way, =C-c C-v C-e= returns as well an error: let: Wrong type argument: stringp, nil This is explainable: that's because the SQL =engine= is not known (not given neither in the header of the code block, neither anywhere in this file). #+begin_src text Debugger entered--Lisp error: (wrong-type-argument stringp nil) intern(nil) (let ((--cl-var-- ...)) (cond (... ...) (... ...) (... ...) (t ...))) (case (intern engine) ((quote msosql) (format osql %s -s \\ -i %s -o %s ... ... ...)) ((quote mysql) (format mysql %s %s %s ... ... ...)) ((quote postgresql) (format psql -A -P footer=off -F \\ -f %s -o %s %s ... ... ...)) (t (error no support for the %s sql engine engine))) (let* ((result-params ...) (cmdline ...) (engine ...) (in-file ...) (out-file ...) (header-delim ) (command ...)) (with-temp-file in-file (insert ...)) (message command) (shell-command command) (if (or ... ... ... ... ...) (with-temp-buffer ...) (with-temp-buffer ... ... ...))) org-babel-execute:sql(-- add column `$column' (if column does not exist yet)\nIF NOT EXISTS (SELECT *\n FROM INFORMATION_SCHEMA.COLUMNS\n WHERE TABLE_NAME = '$table'\n AND COLUMN_NAME = '$column')\nBEGIN\nALTER TABLE $table\nADD $column $type $nullability\nEND ((:var table . dossier) (:var column . pfiResetDate) (:var type . date) (:var nullability . NULL) (:colname-names) (:rowname-names) (:result-params silent replace) (:result-type . value) (:comments . ) (:shebang . ) (:cache . no) (:padline . ) (:noweb . no) (:tangle . no) (:exports . code) (:results . silent) (:padnewline . yes) (:hlines . no) (:session . none) (:result-type . value) (:result-params replace) (:rowname-names) (:colname-names))) #+end_src Though, I guess we should have a proper manner to report that some necessary arguments are missing, instead of failing with a unclear message. ** Other weirdnesses While the variable =org-babel-library-of-babel= contains the ingested code (here, of =add-column-in-table=), the variable =org-babel-lob-files= is =nil=!? ** Speed commands Speed commands don't work on the =#+call= lines. If I press =v= or =e=, they're inserted verbatim. Can you help me understand the 1^st point of these 4? Thanks a lot!! Best regards,
Re: [O] Prompt for time when clocking in?
Some progress -- I used Nick's suggestion combined with the org-read-date function. This is my first attempt -- It will prompt you for a time, and clock in to the headline that the cursor is on with that time. (defun njn/clock-in-at-time() (interactive) (setq start-time (org-read-date 't 't)) (org-clock-in nil start-time) ) It's a bit wonky if you clock in to a past time, and then you want to resolve that clock, but my main use-case for now is this: 1) I start doing something 2) I forgot to clock in 3) I don't want to press 8 keys in order to clock in 15 minutes ago. This solution should work for now. Although, I could see it being a handy way to prompt for clock-in *and* clock-out times. Thanks for the suggestions, --Nate On Wed, Oct 19, 2011 at 10:35 AM, Nick Dokos nicholas.do...@hp.com wrote: John Hendy jw.he...@gmail.com wrote: On Wed, Oct 19, 2011 at 9:54 AM, Nathan Neff nathan.n...@gmail.com wrote: Is there a way to pull up a date/time prompt when clocking in to a task? Sometimes, I started a task 15 minutes ago, and have to go through the following steps: 1) clock in on the task, 2) Go to the CLOCK section for that header and press tab to open it 3) Fix the clock-in time If it's not built in, does anyone have any slick functions that would accomplish the same thing? :-) Check out a thread I started a bit back on this exact topic: --- http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40498.html It wasn't exactly what I expected, the suggestion by Bernt for `M-x org-resolve-clocks` works reasonably well if you are trying to clock back-to-back activities. Post back after you read that perhaps? Maybe you'll find something helpful. org-clock-in takes an optional start-time argument which is used instead of the current time when non-nil. So I tried (setq ct (current-time)) (setq start-time (cons (car ct) (list (- (cadr ct) 900) (caddr ct and started a clock on a task with ESC ESC : (org-clock-in nil start-time) and it got clocked in 15 minutes before the current time. Now I don't propose this as a good UI :-), but it would require just a small wrapper for it to dtrt. HTH, Nick
Re: [O] [babel] Expand code is failing on a #+call line
Hi Eric, Eric Schulte wrote: This is a minor point, but would you mind structuring your emails with an introduction of pure-prose (no embedded examples), saving the examples for the end (footnotes work well for this). I often find it disjointing to try to ingest large code example while simultaneously trying to figure out the high-level point of the email. Point noted. OK. As to this specific question... I am not sure where you are trying to expand a code block. It seems as if you are trying to expand a call line, but I do not believe that is supposed to be possible. As for any other code block, all I want is to see its expanded (instantiated) version before I run it. Is this not doable when you call the code block remotely (I mean: from a #+call line, instead of from the code block itself)? If not, does that mean we better not put code block into the lob, when we're interested by having a look at their expanded form? Best regards, Seb Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, * Config ** Some file to be ingested Let's say I have this code in a =my-lob.org= file: #+srcname: add-column-in-table(table=, column=, type=, nullability=) #+begin_src sql -- add column `$column' (if column does not exist yet) IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '$table' AND COLUMN_NAME = '$column') BEGIN ALTER TABLE $table ADD $column $type $nullability END #+end_src ** In .emacs ... which I ingest at Emacs startup through the lines: #+begin_src emacs-lisp (require 'ob-lob) (org-babel-lob-ingest ~/org/my-lob.org) #+end_src * Some other document ** Source params In some other document, I have a table with columns I'd like to add in a database: #+results: params | table | column | type| nullability | |-++-+-| | dossier | pfiResetDate | date| NULL| | dossier | pfiResetOprID | tinyint | NULL| | dossier | pfiResetOprNom | varchar(64) | NULL| Normally, I could call statements like this: #+call: add-column-in-table(table=params[2,0], column=params[2,1], type=params[2,2], nullability=params[2,3]) But... ** Expand code is failing =C-c C-v C-v= does generate an error: setf: Wrong type argument: consp, nil #+begin_src text Debugger entered--Lisp error: (wrong-type-argument consp nil) setcar(nil ((:cache . ) (:comments . ) (:exports . ) (:noweb . ) (:padline . ) (:results . ) (:shebang . ) (:tangle . ))) (setf (nth 2 info) (sort (org-babel-merge-params ... params) (lambda ... ...))) (let* ((info ...) (lang ...) (params ...) (body ...) (expand-cmd ...) (assignments-cmd ...) (expanded ...)) (org-edit-src-code nil expanded (concat *Org-Babel Preview ... [ lang ]*))) org-babel-expand-src-block() call-interactively(org-babel-expand-src-block nil nil) #+end_src This stays very unclear to me... ** Execute code is failing By the way, =C-c C-v C-e= returns as well an error: let: Wrong type argument: stringp, nil This is explainable: that's because the SQL =engine= is not known (not given neither in the header of the code block, neither anywhere in this file). #+begin_src text Debugger entered--Lisp error: (wrong-type-argument stringp nil) intern(nil) (let ((--cl-var-- ...)) (cond (... ...) (... ...) (... ...) (t ...))) (case (intern engine) ((quote msosql) (format osql %s -s \ \ -i %s -o %s ... ... ...)) ((quote mysql) (format mysql %s %s %s ... ... ...)) ((quote postgresql) (format psql -A -P footer=off -F \\ -f %s -o %s %s ... ... ...)) (t (error no support for the %s sql engine engine))) (let* ((result-params ...) (cmdline ...) (engine ...) (in-file ...) (out-file ...) (header-delim ) (command ...)) (with-temp-file in-file (insert ...)) (message command) (shell-command command) (if (or ... ... ... ... ...) (with-temp-buffer ...) (with-temp-buffer ... ... ...))) org-babel-execute:sql(-- add column `$column' (if column does not exist yet)\nIF NOT EXISTS (SELECT *\n FROM INFORMATION_SCHEMA.COLUMNS\n WHERE TABLE_NAME = '$table'\n AND COLUMN_NAME = '$column')\nBEGIN\nALTER TABLE $table\n ADD $column $type $nullability\nEND ((:var table . dossier) (:var column . pfiResetDate) (:var type . date) (:var nullability . NULL) (:colname-names) (:rowname-names) (:result-params silent replace) (:result-type . value) (:comments . ) (:shebang . ) (:cache . no) (:padline . ) (:noweb . no) (:tangle . no) (:exports . code) (:results . silent) (:padnewline . yes) (:hlines . no) (:session . none) (:result-type . value) (:result-params replace) (:rowname-names) (:colname-names))) #+end_src Though, I guess we should have a proper manner to report that some necessary arguments are missing, instead of failing
Re: [O] Prompt for time when clocking in?
Nathan Neff nathan.n...@gmail.com wrote: Some progress -- I used Nick's suggestion combined with the org-read-date function. This is my first attempt -- It will prompt you for a time, and clock in to the headline that the cursor is on with that time. (defun njn/clock-in-at-time() (interactive) (setq start-time (org-read-date 't 't)) (org-clock-in nil start-time) ) Two minor nits: t is a constant so you don't need to quote it; emacs-lisp mode helps with indentation (putting it in a code block - see below - in an org file and using C-c ' to edit it works wonderfully). I'm not sure whether 'tis better to specify relative or absolute times (let's see: I should have clocked in 15 mins ago vs Let's see: I should have clocked in at 12:20), but just in case you want to try the alternatives, here are two dummy function functions for the two alternatives - they just print the result time in the echo area. The rel time can use a prefix arg (ESC -15 M-x rel/dummy-clock-in-at-time) or the minibuffer if no prefix arg is specified (and you might want to bias it towards the past, so 15 = 15 mins ago and -15 = 15 mins from now, but that might be a bit perverse). FWIW, I think I would tend to prefer your implementation, but since I clock nothing, I'm no expert :-) Nick #+begin_src elisp (defun rel/dummy-clock-in-at-time (nmin) (interactive N+/-minutes: ) (setq start-time (time-add (current-time) (seconds-to-time (* nmin 60 (message (format-time-string %H:%M:%S start-time))) (defun abs/dummy-clock-in-at-time() (interactive) (setq start-time (org-read-date t t)) (message (format-time-string %H:%M:%S start-time))) #+end_src It's a bit wonky if you clock in to a past time, and then you want to resolve that clock, but my main use-case for now is this: 1) I start doing something 2) I forgot to clock in 3) I don't want to press 8 keys in order to clock in 15 minutes ago. This solution should work for now. Although, I could see it being a handy way to prompt for clock-in *and* clock-out times. Thanks for the suggestions, --Nate On Wed, Oct 19, 2011 at 10:35 AM, Nick Dokos nicholas.do...@hp.com wrote: John Hendy jw.he...@gmail.com wrote: On Wed, Oct 19, 2011 at 9:54 AM, Nathan Neff nathan.n...@gmail.com wrote: Is there a way to pull up a date/time prompt when clocking in to a task? Sometimes, I started a task 15 minutes ago, and have to go through the following steps: 1) clock in on the task, 2) Go to the CLOCK section for that header and press tab to open it 3) Fix the clock-in time If it's not built in, does anyone have any slick functions that would accomplish the same thing? :-) Check out a thread I started a bit back on this exact topic: --- http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40498.html It wasn't exactly what I expected, the suggestion by Bernt for `M-x org-resolve-clocks` works reasonably well if you are trying to clock back-to-back activities. Post back after you read that perhaps? Maybe you'll find something helpful. org-clock-in takes an optional start-time argument which is used instead of the current time when non-nil. So I tried (setq ct (current-time)) (setq start-time (cons (car ct) (list (- (cadr ct) 900) (caddr ct and started a clock on a task with ESC ESC : (org-clock-in nil start-time) and it got clocked in 15 minutes before the current time. Now I don't propose this as a good UI :-), but it would require just a small wrapper for it to dtrt. HTH, Nick
Re: [O] Prompt for time when clocking in?
Two minor nits: t is a constant so you don't need to quote it; emacs-lisp mode helps with indentation (putting it in a code block - see below - in an org file and using C-c ' to edit it works wonderfully). Thanks for your suggestions re: using Emacs to edit lisp code and using the t in lieu of 't -- I appreciate these types of style/coding comments immensely! I'm not sure whether 'tis better to specify relative or absolute times (let's see: I should have clocked in 15 mins ago vs Let's see: I should have clocked in at 12:20), but just in case you want to try the alternatives, here are two dummy function functions for the two alternatives - they just print the result time in the echo area. Nick, I like the ability to just type 15, but I also like the ability to use the familiar org-calendar in case I want to get fancier (for example, I forgot to clock something that I worked on yesterday) It would be a cool feature of org-read-date to be able to type -15M and have org-read-date go back 15 minutes from the current date/time. I played around with org-read date for something like -15m and -15M, but the -15m went back 15 *months*, not minutes. Does anyone know if there's a way to specify a relative *time* using org-read-date? For example, something like -15M would be 15 minutes earlier? Thanks, --Nate The rel time can use a prefix arg (ESC -15 M-x rel/dummy-clock-in-at-time) or the minibuffer if no prefix arg is specified (and you might want to bias it towards the past, so 15 = 15 mins ago and -15 = 15 mins from now, but that might be a bit perverse). FWIW, I think I would tend to prefer your implementation, but since I clock nothing, I'm no expert :-) Nick #+begin_src elisp (defun rel/dummy-clock-in-at-time (nmin) (interactive N+/-minutes: ) (setq start-time (time-add (current-time) (seconds-to-time (* nmin 60 (message (format-time-string %H:%M:%S start-time))) (defun abs/dummy-clock-in-at-time() (interactive) (setq start-time (org-read-date t t)) (message (format-time-string %H:%M:%S start-time))) #+end_src It's a bit wonky if you clock in to a past time, and then you want to resolve that clock, but my main use-case for now is this: 1) I start doing something 2) I forgot to clock in 3) I don't want to press 8 keys in order to clock in 15 minutes ago. This solution should work for now. Although, I could see it being a handy way to prompt for clock-in *and* clock-out times. Thanks for the suggestions, --Nate On Wed, Oct 19, 2011 at 10:35 AM, Nick Dokos nicholas.do...@hp.com wrote: John Hendy jw.he...@gmail.com wrote: On Wed, Oct 19, 2011 at 9:54 AM, Nathan Neff nathan.n...@gmail.com wrote: Is there a way to pull up a date/time prompt when clocking in to a task? Sometimes, I started a task 15 minutes ago, and have to go through the following steps: 1) clock in on the task, 2) Go to the CLOCK section for that header and press tab to open it 3) Fix the clock-in time If it's not built in, does anyone have any slick functions that would accomplish the same thing? :-) Check out a thread I started a bit back on this exact topic: --- http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40498.html It wasn't exactly what I expected, the suggestion by Bernt for `M-x org-resolve-clocks` works reasonably well if you are trying to clock back-to-back activities. Post back after you read that perhaps? Maybe you'll find something helpful. org-clock-in takes an optional start-time argument which is used instead of the current time when non-nil. So I tried (setq ct (current-time)) (setq start-time (cons (car ct) (list (- (cadr ct) 900) (caddr ct and started a clock on a task with ESC ESC : (org-clock-in nil start-time) and it got clocked in 15 minutes before the current time. Now I don't propose this as a good UI :-), but it would require just a small wrapper for it to dtrt. HTH, Nick
Re: [O] [babel] Expand code is failing on a #+call line
As to this specific question... I am not sure where you are trying to expand a code block. It seems as if you are trying to expand a call line, but I do not believe that is supposed to be possible. As for any other code block, all I want is to see its expanded (instantiated) version before I run it. Is this not doable when you call the code block remotely (I mean: from a #+call line, instead of from the code block itself)? That is correct. There is no reason (that I can think of at the moment) why this functionality could not be added, but currently the code block preview functionality expects to be called from within a code block. If not, does that mean we better not put code block into the lob, when we're interested by having a look at their expanded form? Yes, given the current state of affairs that is correct. Best -- Eric Best regards, Seb Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, * Config ** Some file to be ingested Let's say I have this code in a =my-lob.org= file: #+srcname: add-column-in-table(table=, column=, type=, nullability=) #+begin_src sql -- add column `$column' (if column does not exist yet) IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '$table' AND COLUMN_NAME = '$column') BEGIN ALTER TABLE $table ADD $column $type $nullability END #+end_src ** In .emacs ... which I ingest at Emacs startup through the lines: #+begin_src emacs-lisp (require 'ob-lob) (org-babel-lob-ingest ~/org/my-lob.org) #+end_src * Some other document ** Source params In some other document, I have a table with columns I'd like to add in a database: #+results: params | table | column | type| nullability | |-++-+-| | dossier | pfiResetDate | date| NULL| | dossier | pfiResetOprID | tinyint | NULL| | dossier | pfiResetOprNom | varchar(64) | NULL| Normally, I could call statements like this: #+call: add-column-in-table(table=params[2,0], column=params[2,1], type=params[2,2], nullability=params[2,3]) But... ** Expand code is failing =C-c C-v C-v= does generate an error: setf: Wrong type argument: consp, nil #+begin_src text Debugger entered--Lisp error: (wrong-type-argument consp nil) setcar(nil ((:cache . ) (:comments . ) (:exports . ) (:noweb . ) (:padline . ) (:results . ) (:shebang . ) (:tangle . ))) (setf (nth 2 info) (sort (org-babel-merge-params ... params) (lambda ... ...))) (let* ((info ...) (lang ...) (params ...) (body ...) (expand-cmd ...) (assignments-cmd ...) (expanded ...)) (org-edit-src-code nil expanded (concat *Org-Babel Preview ... [ lang ]*))) org-babel-expand-src-block() call-interactively(org-babel-expand-src-block nil nil) #+end_src This stays very unclear to me... ** Execute code is failing By the way, =C-c C-v C-e= returns as well an error: let: Wrong type argument: stringp, nil This is explainable: that's because the SQL =engine= is not known (not given neither in the header of the code block, neither anywhere in this file). #+begin_src text Debugger entered--Lisp error: (wrong-type-argument stringp nil) intern(nil) (let ((--cl-var-- ...)) (cond (... ...) (... ...) (... ...) (t ...))) (case (intern engine) ((quote msosql) (format osql %s -s \ \ -i %s -o %s ... ... ...)) ((quote mysql) (format mysql %s %s %s ... ... ...)) ((quote postgresql) (format psql -A -P footer=off -F \\ -f %s -o %s %s ... ... ...)) (t (error no support for the %s sql engine engine))) (let* ((result-params ...) (cmdline ...) (engine ...) (in-file ...) (out-file ...) (header-delim ) (command ...)) (with-temp-file in-file (insert ...)) (message command) (shell-command command) (if (or ... ... ... ... ...) (with-temp-buffer ...) (with-temp-buffer ... ... ...))) org-babel-execute:sql(-- add column `$column' (if column does not exist yet)\nIF NOT EXISTS (SELECT *\n FROM INFORMATION_SCHEMA.COLUMNS\n WHERE TABLE_NAME = '$table'\n AND COLUMN_NAME = '$column')\nBEGIN\nALTER TABLE $table\n ADD $column $type $nullability\nEND ((:var table . dossier) (:var column . pfiResetDate) (:var type . date) (:var nullability . NULL) (:colname-names) (:rowname-names) (:result-params silent replace) (:result-type . value) (:comments . ) (:shebang . ) (:cache . no) (:padline . ) (:noweb . no) (:tangle . no) (:exports . code) (:results . silent) (:padnewline . yes) (:hlines . no) (:session . none) (:result-type . value) (:result-params replace) (:rowname-names) (:colname-names))) #+end_src Though, I guess we should have a proper manner to report that some necessary arguments are missing, instead of failing with a unclear message. ** Other weirdnesses While the variable
[O] [babel] Cannot use R and sh
Hi all, when using R and shell commands, the shell commands are sent to the R buffer. I guess this has something to do with the session argument?! # test.org # #+property: session *R* #+BEGIN_SRC R ## comment 1+1 #+END_SRC #+results: : 2 #+BEGIN_SRC sh ls -a #+END_SRC #+results: : Error: object 'a' not found # test.org # Thanks, Bernd Org-mode version 7.7 (release_7.7.393.g8caa)
Re: [O] [babel] Cannot use R and sh
Bernd Weiss bernd.we...@uni-koeln.de wrote: Hi all, when using R and shell commands, the shell commands are sent to the R buffer. I guess this has something to do with the session argument?! # test.org # #+property: session *R* #+BEGIN_SRC R ## comment 1+1 #+END_SRC #+results: : 2 #+BEGIN_SRC sh ls -a #+END_SRC #+results: : Error: object 'a' not found # test.org # AFAIK, the syntax is (note the BABEL and the :session) #+BABEL: :session *R* With that, I can certainly reproduce what you get and it is indeed the global session that causes it. If you want a global session for all the other code blocks but want to override it for the single shell block, you can do: #+BEGIN_SRC sh :session *SH* ls -a #+END_SRC Nick
Re: [O] [babel] Cannot use R and sh
On 20.10.2011 14:49, Nick Dokos wrote: [...] AFAIK, the syntax is (note the BABEL and the :session) #+BABEL: :session *R* With that, I can certainly reproduce what you get and it is indeed the global session that causes it. If you want a global session for all the other code blocks but want to override it for the single shell block, you can do: #+BEGIN_SRC sh :session *SH* ls -a #+END_SRC Thanks, Nick, for your reply! I hadn't thought about overriding the R session. Good idea! With respect to the #+BABEL... syntax, I vaguely remember that this is deprecated. The Org Mode Manual, however, (still) mentions both ways... http://orgmode.org/org.html#Header-arguments-in-Org_002dmode-properties. Again, thanks, Bernd
Re: [O] [babel] Specifying buffer-wide header arguments: #+property vs #+babel (was: Cannot use R and sh)
On 20.10.2011 14:58, Bernd Weiss wrote: [...] With respect to the #+BABEL... syntax, I vaguely remember that this is deprecated. The Org Mode Manual, however, (still) mentions both ways... http://orgmode.org/org.html#Header-arguments-in-Org_002dmode-properties. Earlier this year, Dan Davison wrote: Please note that it is possible to make an equivalent setting using #+PROPERTY: session *R* In fact, I suspect we are going to drop #+BABEL entirely, so please consider it deprecated and use this form instead. http://lists.gnu.org/archive/html/emacs-orgmode/2011-02/msg00672.html I am wondering if this statement still holds true? Bernd
Re: [O] [babel] Specifying buffer-wide header arguments: #+property vs #+babel
Bernd Weiss bernd.we...@uni-koeln.de writes: On 20.10.2011 14:58, Bernd Weiss wrote: [...] With respect to the #+BABEL... syntax, I vaguely remember that this is deprecated. The Org Mode Manual, however, (still) mentions both ways... http://orgmode.org/org.html#Header-arguments-in-Org_002dmode-properties. Earlier this year, Dan Davison wrote: Please note that it is possible to make an equivalent setting using #+PROPERTY: session *R* In fact, I suspect we are going to drop #+BABEL entirely, so please consider it deprecated and use this form instead. http://lists.gnu.org/archive/html/emacs-orgmode/2011-02/msg00672.html I am wondering if this statement still holds true? Yes, I would hope to drop #+BABEL: this at some point. In fact perhaps this should happen sooner rather than later i.e., before the last merge of Org-mode into Emacs before the release of Emacs24. If there is no complaint I may make this change in the Org-mode git repository now. Best -- Eric Bernd -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] Private flag or property
Hi! I am still in the process of converting (lots!) of old data into Org-mode format. I stumbled over a private-flag PalmOS datebook used to maintain. Is there a *common* way of expressing a private flag/property yet? Or is there no pseudo-standard and I should stick to my «:PRIVATE: True» property I am thinking of? (Is there a necessity for the «True» string in my example (property without value)? -- Karl Voit
[O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi, I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [PATCH] Check marker is valid before use
lisp/org-agenda.el | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index bf03b68c..f4b8bcbf 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -6784,13 +6784,13 @@ (defun org-agenda-previous-line () (defun org-agenda-do-context-action () Show outline path and, maybe, follow mode window. (let ((m (org-get-at-bol 'org-marker))) -(if (and org-agenda-follow-mode m) - (if org-agenda-follow-indirect - (org-agenda-tree-to-indirect-buffer) - (org-agenda-show))) -(if (and m org-agenda-show-outline-path) - (org-with-point-at m - (org-display-outline-path t) +(when (and (markerp m) (marker-buffer m)) + (and org-agenda-follow-mode + (if org-agenda-follow-indirect + (org-agenda-tree-to-indirect-buffer) +(org-agenda-show))) + (and org-agenda-show-outline-path + (org-with-point-at m (org-display-outline-path t)) (defun org-agenda-show-priority () Show the priority of the current item. -- 1.7.7
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Yes, but the #+PROPERTIES line has nothing to do with org properties. It *only* affects code blocks, no? Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Nick and Eric, Nick Dokos wrote: Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). If you'd have asked me, I would have chosen #+BABEL instead of #+PROPERTIES, as it made it clear who owned those directives, to whom they were targeted. Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? However, I've been convinced by Eric's arguments. The fact you already can mix BABEL properties in subtree PROPERTIES... Yes, but the #+PROPERTIES line has nothing to do with org properties. It *only* affects code blocks, no? But, I guess you're right, Nick: not the other way around. So, I don't know anymore what to think... I do well agree that properties has not a clear-cut meaning anymore; this is a very general word. Now, if I had to choose between #+PROPERTY and #+PROPERTIES, I would favor the last one, as it is some place where you can stuff many properties -- and to reflect what's already use for the export options: there you put the options under the OPTIONS meta-keyword. In the plural form. Just my 2 cents. Whatever your choice, I'll follow it. And I always prefer to reduce the number of synonyms, and have just one official form[1]. Best regards, Seb Footnotes: [1] I have the same annoying feelings with #+SOURCE, #+SRCNAME, #+FUNCTION, #+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd prefer deprecating an old form when a better one is found. -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Whoa -- before this gets more confusing: Eric, did you push up a (new, or at least so far undocumented in the manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien seem to understand you? Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY line or :PROPERTIES: drawer, as provided in the manual? Yours, Christian (lamenting the demise of the #+BABEL header I'd just recently started to use) On 10/20/11 10:12 PM, Eric Schulte wrote: Nick Dokosnicholas.do...@hp.com writes: Eric Schulteschulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Best -- Eric
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Christian Moe m...@christianmoe.com wrote: Whoa -- before this gets more confusing: Eric, did you push up a (new, or at least so far undocumented in the manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien seem to understand you? Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY line or :PROPERTIES: drawer, as provided in the manual? Here's the commit log (I think it reflects the code changes faithfully): , | commit 04a978fde525a442f9de14d1a67783edd5c9cb78 | Author: Eric Schulte schulte.e...@gmail.com | Date: Thu Oct 20 13:31:20 2011 -0600 | | removing #+BABEL: lines in favor of general #+PROPERTIES: lines | | * lisp/ob.el (org-babel-params-from-buffer): Removing #+BABEL: lines | in favor of general #+PROPERTIES: lines. | | * doc/org.texi (Buffer-wide header arguments): Removing documentation | of the defunct #+BABEL: structure. ` So #+BABEL was traded for #+PROPERTIES. Nick Yours, Christian (lamenting the demise of the #+BABEL header I'd just recently started to use) On 10/20/11 10:12 PM, Eric Schulte wrote: Nick Dokosnicholas.do...@hp.com writes: Eric Schulteschulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? Also, there is the general concept of properties (the stuff that the property API applies to). Unless there is an underlying unity of which I'm unaware, I'd strongly suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus an easy-template for easy insertion). Code blocks already piggy-back off of subtree properties pulling their header arguments out of the properties specified on the subtree level. Given that header arguments and properties are already thus interleaved I believe that properties should be used on the file-wide level as well, rather than introducing another synonymous keyword which adds no new functionality. Does that make sense? Best -- Eric
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Oh! Thank you for making this clear, I had assumed that #+PROPERTIES: lines were an integral part of Org-mode which code block header arguments were simply making use of. Having read the section of the info manual you point out above I see that I was mistaken. I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. Thanks -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte schulte.e...@gmail.com wrote: 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. Is the 'results' without a preceding colon or is that a typo? -- Suvayu Open source is the future. It sets us free.
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, Eric Schulte wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Oh! Thank you for making this clear, I had assumed that #+PROPERTIES: lines were an integral part of Org-mode which code block header arguments were simply making use of. Having read the section of the info manual you point out above I see that I was mistaken. I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. I just have one question, as I'm puzzled by the lack of `:' in front of the properties: how do we distinguish the argument value from the argument name? For example, how do we translate, in the new syntax, #+BABEL::results output code append (where `:results' is the name, and `output', `code' and `append' are values)? Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: ... I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. Thanks, Nick
[O] [RFC] Standardized code block keywords
[1] I have the same annoying feelings with #+SOURCE, #+SRCNAME, #+FUNCTION, #+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd prefer deprecating an old form when a better one is found. This point of view has been raised previously both on the mailing list and in the #org-mode IRC chat room. I think it is time that we decided as a community what we want to do about the prevalence of code block synonyms -- we should make this decision before the release of Emacs24 after which syntax will become harder to change. There are currently a number of instances of synonymous keywords when dealing with code blocks, specifically. named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data Ideally if we limit each of the above to only one alternative we could simplify the specification of code blocks in Org-mode making them easier to learn and use and removing some of the mystery around their syntax. What does everyone think? Are there suggestions for the best names for each code block entity (either in the list or not in the list)? Are there cases where we want to continue to allow synonyms (e.g., in named data so that results can be used for code block results but data can be used for hand-written data)? Thanks -- Eric Footnotes: [1] named code blocks #+source: foo #+begin_src emacs-lisp 'foo #+end_src #+srcname: foo #+begin_src emacs-lisp 'foo #+end_src #+function: foo #+begin_src emacs-lisp 'foo #+end_src [2] calling external functions #+call: foo() #+lob: foo() [3] named data #+data: something : something #+results: something : something etc... -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
suvayu ali fatkasuvayu+li...@gmail.com writes: Hi Eric, On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte schulte.e...@gmail.com wrote: 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. Is the 'results' without a preceding colon or is that a typo? As with properties specified in :PROPERTIES: blocks under headlines, the colon is not needed, the above is correct. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Coming late to the dance - sorry. I think that's very confusing. Property is an overloaded term in org: we now have the :PROPERTIES: drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and plural forms are already pretty bad). Do the #+PROPERTY and #+PROPERTIES lines have different semantics? I think so: see section 7.1 for a use of the former. AFAICT, the latter only applies to code block header arguments. Oh! Thank you for making this clear, I had assumed that #+PROPERTIES: lines were an integral part of Org-mode which code block header arguments were simply making use of. Having read the section of the info manual you point out above I see that I was mistaken. I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. I just have one question, as I'm puzzled by the lack of `:' in front of the properties: how do we distinguish the argument value from the argument name? For example, how do we translate, in the new syntax, #+BABEL::results output code append (where `:results' is the name, and `output', `code' and `append' are values)? The above would become #+PROPERTY: results output code append Since only one property may be specified per property line there is no need for colons. This mirrors exactly the way the properties are saved under subtrees in :PROPERTY: blocks. Multiple lines may be used to specify multiple properties. e.g., #+PROPERTY: results silent #+PROPERTY: cache yes Best -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: I just have one question, as I'm puzzled by the lack of `:' in front of the properties: how do we distinguish the argument value from the argument name? For example, how do we translate, in the new syntax, #+BABEL::results output code append (where `:results' is the name, and `output', `code' and `append' are values)? #+PROPERTY: results output code append See the aforementioned sec. 7.1 of the manual. Equivalently, * foo :PROPERTIES: :results: output code append :END: That's a consequence of the property syntax. On the code block header line however, you have to have some purely syntactic marker to distinguish properties from their values, hence #+begin_src foo :results output code append :exports both ... The trick is to think of the colon as a delimited (like a comma) not as a part of the property name. Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: ... I've just pushed up what I consider to be a clean implementation. Put briefly the new behavior is that properties may be used to specify header arguments. More completely... 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. I think this should be simple, easy to remember, and it certainly cleaned up the code base. Please let me know what you think of this new setup. Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. I don't know of a good solution for colons. If we decided to add colons then the subtree property blocks would become akward, with entries like ** foo :PROPERTIES: ::results: silent :END: I would say we could look for each value both with and without colons, but property searches of this nature are slow and doubling the speed impact simply for allow colon flexibility doesn't seem to be a good tradeoff. I think this will just have to be something that users will need to learn. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] org-contacts or bbdb?
Hello, I would like to manage my contacts, so that I can - easily search them - add new email addresses from gnus (summary buffer) - complete email addresses in gnus (message buffer and prompts in mini-buffer) - and perhaps more in the future Could you guide me please, what to choose, org-contacts or bbdb? I don't see the advantages of the one or of the other... TIA for any hints! I'm just beginning to learn org-mode, thanks for this nice software! -- Peter
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Eric Schulte schulte.e...@gmail.com wrote: Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. I don't know of a good solution for colons. If we decided to add colons then the subtree property blocks would become akward, with entries like ** foo :PROPERTIES: ::results: silent :END: I would say we could look for each value both with and without colons, but property searches of this nature are slow and doubling the speed impact simply for allow colon flexibility doesn't seem to be a good tradeoff. I think this will just have to be something that users will need to learn. I agree[fn:1]: the point is to simplify the code, not complicate it *and* slow down everything at the same time. Maybe the header args section of the manual can use the colon as delimiter method to explain the equivalent forms and that will suffice. Nick Footnotes: [fn:1] ...but I take some perverse pleasure from the fact that both Suvayu and Seb asked the question :-)
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Other than colon confusion (having to specify ``:results silent'' on the src block header line and ``results silent'' in the #+PROPERTY line to get the same behavior), this looks better. Not sure what (if anything) can or should be done about the colons. I don't know of a good solution for colons. If we decided to add colons then the subtree property blocks would become akward, with entries like ** foo :PROPERTIES: ::results: silent :END: I would say we could look for each value both with and without colons, but property searches of this nature are slow and doubling the speed impact simply for allow colon flexibility doesn't seem to be a good tradeoff. I think this will just have to be something that users will need to learn. I agree[fn:1]: the point is to simplify the code, not complicate it *and* slow down everything at the same time. Maybe the header args section of the manual can use the colon as delimiter method to explain the equivalent forms and that will suffice. I agree, the header argument syntax portion of the documentation could be made more clear, and I did like you explanation to Seb's email. Perhaps you could submit a documentation patch? :) Nick Footnotes: [fn:1] ...but I take some perverse pleasure from the fact that both Suvayu and Seb asked the question :-) I noticed that too, and it no doubt means that this same question will occur to future users. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Thu, 20 Oct 2011 15:52:42 -0600 Eric Schulte schulte.e...@gmail.com wrote: suvayu ali fatkasuvayu+li...@gmail.com writes: Hi Eric, On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte schulte.e...@gmail.com wrote: 2. The existing #+PROPERTY: line may now be used to specify values for header arguments, e.g., #+PROPERTY: results silent would silence all results in the current buffer. Is the 'results' without a preceding colon or is that a typo? As with properties specified in :PROPERTIES: blocks under headlines, the colon is not needed, the above is correct. Thanks a lot Eric. I have never used :PROPERTIES: for Babel, hence I didn't know! Best -- Eric Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] org-contacts or bbdb?
pmli...@free.fr (Peter Münster) writes: Hello, I would like to manage my contacts, so that I can - easily search them - add new email addresses from gnus (summary buffer) - complete email addresses in gnus (message buffer and prompts in mini-buffer) - and perhaps more in the future Could you guide me please, what to choose, org-contacts or bbdb? I don't see the advantages of the one or of the other... TIA for any hints! I used org-contacts but now use bbdb3. I think bbdb does it all and it's quite nice. I don't remember why I dropped Org-contant, but I think I found it hard to manage my contacts in the way I would ideally like to with it. Cheers, Rasmus -- Sent from my Emacs
Re: [O] [RFC] Standardized code block keywords
Eric Schulte schulte.e...@gmail.com writes: [1] I have the same annoying feelings with #+SOURCE, #+SRCNAME, #+FUNCTION, #+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd prefer deprecating an old form when a better one is found. This point of view has been raised previously both on the mailing list and in the #org-mode IRC chat room. I think it is time that we decided as a community what we want to do about the prevalence of code block synonyms -- we should make this decision before the release of Emacs24 after which syntax will become harder to change. There are currently a number of instances of synonymous keywords when dealing with code blocks, specifically. named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data Ideally if we limit each of the above to only one alternative we could simplify the specification of code blocks in Org-mode making them easier to learn and use and removing some of the mystery around their syntax. What does everyone think? Are there suggestions for the best names for each code block entity (either in the list or not in the list)? Are there cases where we want to continue to allow synonyms (e.g., in named data so that results can be used for code block results but data can be used for hand-written data)? Thanks -- Eric Footnotes: [1] named code blocks #+source: foo #+begin_src emacs-lisp 'foo #+end_src #+srcname: foo #+begin_src emacs-lisp 'foo #+end_src #+function: foo #+begin_src emacs-lisp 'foo #+end_src [2] calling external functions #+call: foo() #+lob: foo() [3] named data #+data: something : something #+results: something : something etc... Hi Eric, named code blocks [1] source calling external functions [2] call named data [3] object My motivation for [3] object instead of the suggested alternates is the hope that it will be possible to name things like lists and paragraphs (that aren't results or data) and pass these objects to source code blocks. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Code block evaluation export bug ?
Nick Dokos nicholas.do...@hp.com writes:
While testing my response to Viktor's question, I ran into a problem.
I used a test file that is slightly modified from a previous post of Tom
Dye's:
* R tables
#+TBLNAME: tbl-1
| column1 | column2 |
|-+-|
| 45 | 34 |
| 77 | 56 |
#+tblname: tbl-2
| col1 | col2 |
|--+--|
| a| b|
| c| d|
#+tblname: tbl-3
| c1 | c2 |
|+|
| A | B |
| C | D |
#+BEGIN_SRC R :var x=tbl-1 :var y=tbl-2 :var z=tbl-3 :colnames yes :exports
both :results value
z
#+END_SRC
Evaluating the code block correctly produces the result
,
|
| #+results:
| | c1 | c2 |
| |+|
| | A | B |
| | C | D |
`
but exporting (to ascii, PDF, HTML or ODT) chops off the first row of
the result. For example, here
is the ascii:
,
|
| c1 c2
| +
| CD
`
HTML produces:
,
| pre class=example
| c1 c2
| 1 C D
| /pre
`
Latex:
,
| \begin{center}
| \begin{tabular}{ll}
| c1c2 \\
| \hline
| C D \\
| \end{tabular}
| \end{center}
`
ODT:
,
| table:table table:name= table:style-name=OrgTable
| table:table-column table:style-name=OrgTableColumn/
| table:table-column table:style-name=OrgTableColumn/
|
| table:table-header-rows
| table:table-rowtable:table-cell
| table:style-name=OrgTblCellTtext:p
| text:style-name=OrgTableHeadingLeftc1/text:p/table:table-cell
|
| table:table-cell table:style-name=OrgTblCellTtext:p
| text:style-name=OrgTableHeadingLeftc2/text:p/table:table-cell
| /table:table-row
|
| /table:table-header-rows
|
| table:table-rows
| table:table-rowtable:table-cell
| table:style-name=OrgTblCellTBtext:p
| text:style-name=OrgTableContentsLeftC/text:p/table:table-cell
|
| table:table-cell table:style-name=OrgTblCellTBtext:p
| text:style-name=OrgTableContentsLeftD/text:p/table:table-cell
| /table:table-row
|
| /table:table-rows
|
| /table:table
`
Versions:
GNU Emacs 24.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of
2011-09-13
Org-mode version 7.7 (release_7.7.396.gfaaa)
Nick
Aloha Nick,
I see the same behavior.
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] org-contacts or bbdb?
On Fri, Oct 21 2011, Peter Münster wrote: Hello, I would like to manage my contacts, so that I can - easily search them - add new email addresses from gnus (summary buffer) - complete email addresses in gnus (message buffer and prompts in mini-buffer) - and perhaps more in the future Could you guide me please, what to choose, org-contacts or bbdb? I don't see the advantages of the one or of the other... TIA for any hints! With those requirements, either will probably do fine. I use BBDB because it's very well tuned to gnus, and you can do quite a bit to the database just from the gnus summary/article buffers. As Rasmus mentioned, if you use BBDB you should get version 3, it's significantly better than the previous version. There's a slow movement towards better import/export functions, which I think has been one of the major gripes about BBDB in the past (there are probably more I'm not aware of). Good luck, Eric -- GNU Emacs 24.0.90.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4) of 2011-10-06 on pellet Org-mode version 7.7 (release_7.7.393.g8caa)
[O] Bill-of-materials
Hi, This is a much better version of the little add-on I've written: Bill-of-materials (org-bom.el) I've used this for over 6 months now, daily. If you ever need to quickly make a quote for a client, or simply make easy to-buy list, this should help you. You can find the code here: http://pastebin.com/K11QpQ6Q The tutorial is included with it, but here is an eye-friendly version: http://frozenlock.wordpress.com/2011/10/20/bom-bills-of-materials/ Finally, just to tease you, this is a table generated from various data gathered inside a buffer: #+BEGIN: bom :total t :no-tag t :description t :price t | Component | Quantity | Price | Description | |-+--+---+--| | CDs | 50 | | Not DVDs | | Headset | 1 | | N/A | | Keyboard | 3 | 120 | Used to type | | Mouse | 2 | | N/A | | USB flash drive | 23 | | N/A | |-+--+---+--| | TOTAL: | | 120 | | #+TBLFM: @$3=vsum(@I..@) #+END: Enjoy!
Re: [O] Code block evaluation export bug ?
Thomas S. Dye t...@tsdye.com wrote: Aloha Nick, I see the same behavior. Thanks for confirming! I'm not entirely sure but it seems to be R-specific: when babel does variable assignments in org-babel-R-assign-elisp, it creates temp files /tmp/babel-XXX/R-import-YYY and when the tables are written out to the files, the first row of each table seems to go missing. Nick
Re: [O] [RFC] Standardized code block keywords
Thomas S. Dye t...@tsdye.com wrote: Eric Schulte schulte.e...@gmail.com writes: [1] I have the same annoying feelings with #+SOURCE, #+SRCNAME, #+FUNCTION, #+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd prefer deprecating an old form when a better one is found. This point of view has been raised previously both on the mailing list and in the #org-mode IRC chat room. I think it is time that we decided as a community what we want to do about the prevalence of code block synonyms -- we should make this decision before the release of Emacs24 after which syntax will become harder to change. There are currently a number of instances of synonymous keywords when dealing with code blocks, specifically. named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data Ideally if we limit each of the above to only one alternative we could simplify the specification of code blocks in Org-mode making them easier to learn and use and removing some of the mystery around their syntax. What does everyone think? Are there suggestions for the best names for each code block entity (either in the list or not in the list)? Are there cases where we want to continue to allow synonyms (e.g., in named data so that results can be used for code block results but data can be used for hand-written data)? Thanks -- Eric Footnotes: [1] named code blocks #+source: foo #+begin_src emacs-lisp 'foo #+end_src #+srcname: foo #+begin_src emacs-lisp 'foo #+end_src #+function: foo #+begin_src emacs-lisp 'foo #+end_src [2] calling external functions #+call: foo() #+lob: foo() [3] named data #+data: something : something #+results: something : something etc... Hi Eric, named code blocks [1] source calling external functions [2] call named data [3] object My motivation for [3] object instead of the suggested alternates is the hope that it will be possible to name things like lists and paragraphs (that aren't results or data) and pass these objects to source code blocks. I disagree with Tom on [1]: it should clearly be srcname, in analogy to #+tblname - and also so I don't have to change my files :-} (but see my question about tblname below). I agree on [2] call. I'm confused by [3] so I will say nothing for now, except to ask some questions: are we talking about what a human would use to label a piece of data for consumption by a block (including perhaps the future possibilities of lists and paragraphs that Tom brought up)? what babel would use to label a results block (possibly so that it could be consumed by another block in a chain)? both? would that mean that #+tblname would go the way of the dodo and that tables would be labelled with #+data (or #+object or whatever else we come up with)? Thanks, Nick
Re: [O] Code block evaluation export bug ?
Nick Dokos nicholas.do...@hp.com wrote: Thomas S. Dye t...@tsdye.com wrote: Aloha Nick, I see the same behavior. Thanks for confirming! I'm not entirely sure but it seems to be R-specific: when babel does variable assignments in org-babel-R-assign-elisp, it creates temp files /tmp/babel-XXX/R-import-YYY and when the tables are written out to the files, the first row of each table seems to go missing. I spoke too soon: I don't know what's going on, but the above is probably wrong - please disregard. I'll take another whack at it over the weekend (maybe). Nick
