Re: [O] [RFC] Standardized code block keywords
On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte schulte.e...@gmail.comwrote: Just to make it as easy as possible for everyone Might it be possible to introduce a small flags like obsolete and stable (standard) Old functions, old syntax, etc., might move first to obsolete before completely removed... We could open an older file and if it isn't working, we could try #+PROPERTY: babel-function-set obsolete I think that making use of such a feature is almost as onerous as changing to the new terms (which is a simple search replace, in fact once terms are selected I'll happily share a function on list which can be used to convert all old terms in existing Org-mode files). The problem are not every-day users, but if one is not using org-mode not using for some time, it might be difficult to figure out what has changed - also, I wou't remember in three years time, that these things have changed, and run into problems when trying to open an old org-file (in the case of literae programming not unlikely). But I also see your point - Eric. Would it be an option to include a function which checks if these files do include the old / deprecated keywords, and inform the user? This function could even, in this case here, suggest to do the replacing. This function could be over time extended, whenever in-compatible changes become necessary - it would be a kind of an org-to-org converter or org-version-checker? Concerning voting: Definitely #+call. I don't like the #+srcname, because most of my blocks are not named, and it would look weired (I have never used #+tblname but if I also think that that looks weired if there is no name coming afterwards...). I would vote for: #+src #+object sounds more modern then data. Just an idea (): #+object_begin var x = 1 y = 2 #+end could possible be used for as an alternative for :var ? And the #+results should stay for generated data to keep them separate (will / can be programmatically changed) Cheers, Rainer if it works, we have to modify the code, because obviously the code requires changed to be compatible in the future. However, just for the moment it is still working. This would give people more time to change there code accordingly. As murphy law tells us one will notice that the particular file is broken exact 5 minutes before the meeting with your boss standing behind you yelling print it, print it ;) I know git would be perfect to keep the code base frozen for a certain syntax. However, babel is bundled with org-mode which is bundled with Emacs. Thus, it might be very difficult to tell people they have to use org-babel from git with the tag [org-babel_XX] if they want to use there old style files. AFAIK org-babel does not even come with a own version numbering, right? Alternatively, keep the syntax a little bit longer as it is and create warning messages to point users to future changes (not sure how much time left for emacs24) Warning: #+lob: in line XX is obsolete, please use #+call: in the future. (manual-link) To make is short, is is possible to introduce changes slowly I fear this would simply serve to introduce more complexity and confusion. As for voting: [1] #+function: would be what I would expect from other programming languages. Where an unnamed source code block would be something like a lambda function. However, function as a term is heavily used in many target languages too. This makes parsing, reading and discussing a bit difficult. (I called the function foo, Wait, do you call the org-mode function foo, or the python function foo?) Thus, I vote for #+srcname similar to #+tblname to make sure about the difference between org-babel and the target languages. [2] #+call:, simply because I never can remember lob and the acronym is something difficult for newbies. noted, thanks [3] I tend to #+results: because it fits more to the entire babel syntax. However, earlier on the mailing list people were pointing out that one is going to change results for a unknown source block (that was the reason data was introduced) and I think this is a valid argument. Maybe data and results should be both valid if only to pleasure human thinking. However, if I understood correctly, maybe data could be changed to be more some type of constant? That is, #+data: foo can not be changed by a source code block named foo (because it isn't a result but data) but only by human (as a data input). Does this make sense? yes, I'll mark you down for data and results, which I think is a perfectly fine option. Thanks for sharing -- Eric Totti -- Eric Schulte http://cs.unm.edu/~eschulte/ -- 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
Re: [O] [RFC] Standardized code block keywords
On Tue, Oct 25, 2011 at 8:52 AM, Rainer M Krug r.m.k...@gmail.com wrote: On Fri, Oct 21, 2011 at 7:37 PM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Eric, Eric Schulte wrote: Now, between srcname and source: I'm used to whatever my Yasnippet is entering for me. That's currently srcname. I don't have a strong opinion, though, to choose one over the other, except that I like Nick's argument with the table analogy. I agree on [2] call. I clearly agree on call as well. noted, thanks I think you'll get unanimity on that one. Here, I'd like to ask: what about sbe? In my own understanding, it's a call, absolutely similar to call. Is there a technical reason to be forced to differentiate both? If no, can we use call as well instead of sbe? The only difference is that sbe is a function name, and to name a function call (a function which will take up that term in the entire Emacs-lisp namespace across all applications) seems somewhat pushy. OK. Point understood. May I suggest to try to find a better name, still? Once we're at it, modifying one extra line in the documentation won't hurt. I don't know what others find, but I've never understood what it meant. OK, now (since yesterday, in fact), I know it means source block evaluation, but that's not really intuitive. I'd opt for ob-call (package name + call) or something like that, if I could choose. 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)? For point 3, Eric, I guess that whichever term is chosen, that does not mean that results will change (I mean: when it's a result of a block execution)? I was expecting you'd always keep results for auto-inserted results (after a code block evaluation). But it makes sense to prefer the one term that will win. I would definitely keep #+results as this marks it as an *output* which can change during the next evaluation, and not an input, which has to be modified by hand. I would actually go so far and say that #+results *can be* src or object (using these terms), but is in itself *not* identifying anything, apart from this is the result of an evaluation. So: #+results #+object_begin . . . #+end would be the result of an evaluation. One could even, for clarities sake, say that #+object if no #+results is in the line before, is a synonym for #+input (or #+constant) #+object_begin . . . #+end Cheers, Rainer I would be happy for results to change to data or tblname (if a table) or whatever else is selected. OK, clear. In other words, if we choose for object, we still will have the possibility to use results (automatically generated) and object to refer to something we want to use in another call? named data [3] -- tblname resname results data I don't specifically like resname. I would keep results for automatically generated results. I do like data, but can learn to like object as a more generic term, future-proof for coming extensions. I'll mark you down as undecided for this term. :) Yep! I'm open to any suggestion you'll make. Last remark: we could get one step further and wonder if it wouldn't be good to impose a single way to pass variables? We currently have two different mechanisms: #+srcname: convert-date-to-French-format #+begin_src sql :var column= CONVERT(varchar(10), $column, 103) AS $column #+end_src and #+srcname: convert-date-to-French-format(column=) #+begin_src sql CONVERT(varchar(10), $column, 103) AS $column #+end_src I guess that the first one is easier if we want to construct complex variable values (which call Emacs Lisp code or such), but... I don't feel that this example causes as much confusion, but if I'm wrong I am open to change on this front. Although the only possible change here would be to remove the second option as the first method of specifying variables is central to code block management. Just that I remember both syntaxes weren't handled the same way for error reporting (remember, when there is no default value: in one case, you can get the name of the faulty block; in the other, not), and that makes me think is not as simple as an alias. Hence, your Babel code is or can become different just because there are different alternatives to write certain things down. Then, as a user, I always wonder what's
Re: [O] [RFC] Standardized code block keywords
Am Dienstag 25 Oktober 2011, 03:30:46 schrieb Eric Schulte: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Daniel, Daniel Bausch wrote: named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data what about #+name: for [1] and [3], and #+call: for [2] ? That a table or list contains data is obvious. The only thing, the additional line is for, is to name it. As Eric showed us, this is not always to name it... If the table is the results of an unamed block, you will have #+name: followed by no name! #+name: | line 1 | data1 | | line 2 | data2 | what I also find quite disturbing. I also find this to be disconcerting. -- Eric Best regards, Seb Then maybe #+results for (anonymous) results only, but #+name for anything else from [1] and [3]. Wasn't there a concept of linking a results block to its originiating source block by some id and we need a place to put the checksum in. So I see some arguments for treating results special. But for the others I do not see pressing arguments against a common name at the moment. However, I'd like to ask, what happens, if one refers to a name of a source block where data is expected, does it then refer to the results produced by that source block? How are such situations handeled at the moment? In other words: is there any type checking? Type checking could be facilitated by using different words, although I think that is not neccessary, because there are other means to distinguish the type of a block (look at the next line in the buffer). Daniel
Re: [O] [RFC] Standardized code block keywords
#+object_begin var x = 1 y = 2 #+end I was thinking on similar lines. This together with Nicolas's suggestion of one name will be wonderful. I think it is easier to explain what I think by means of an example. In case of lisp, the SAME variable name could either act as a function or a variable. The way the VARIABLE NAME is INTERPRETED, DEPENDS ON THE CONTEXT in which it needs to be interpreted. Similarly a VAR could be EVALLED or just be a QUOTED SYMBOL. Coming back to the above example - If the HANDLE for the above block (whatever you call it), appears as a PARAM OF BABEL CALL it would be interpreted as a param list. Think `apply' and `rest args' in the elisp world. Another near equivalent would be COERCING or CASTING. In abstract terms, the above block could be treated as a TABLE. In some sense, a LIST or a LIST OF LIST could be coerced in to a TABLE. I consider babel to be a VM and an execution environment - i.e., as a scripting environment for Org. So definitely we can borrow ideas from the existing languages and extend it. In summary, what I am saying is EVERYTHING IS A BLOB. The way a BLOB is INTERPRETED depends on the CONTEXT in which interpretation happens. A BLOB in and of itself is but JUST A BLOB and has NO INHERENT meaning. I don't use babel myself so I may not be using the right set of words. Also it is not my intention to hijack the thread. Jambunathan K.
Re: [O] [RFC] Standardized code block keywords
Hi Daniel, Daniel Bausch wrote: Am Dienstag 25 Oktober 2011, 03:30:46 schrieb Eric Schulte: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Daniel Bausch wrote: named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data what about #+name: for [1] and [3], and #+call: for [2] ? That a table or list contains data is obvious. The only thing, the additional line is for, is to name it. As Eric showed us, this is not always to name it... If the table is the results of an unamed block, you will have #+name: followed by no name! #+name: | line 1 | data1 | | line 2 | data2 | what I also find quite disturbing. I also find this to be disconcerting. -- Eric Then maybe #+results for (anonymous) results only, but #+name for anything else from [1] and [3]. Just wanted to say I like the idea of keeping results for (at least) output of an anonymous call. Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Standardized code block keywords
Hi Rainer, Rainer M Krug wrote: On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte schulte.e...@gmail.comwrote: Just to make it as easy as possible for everyone Might it be possible to introduce a small flags like obsolete and stable (standard) Old functions, old syntax, etc., might move first to obsolete before completely removed... We could open an older file and if it isn't working, we could try #+PROPERTY: babel-function-set obsolete I think that making use of such a feature is almost as onerous as changing to the new terms (which is a simple search replace, in fact once terms are selected I'll happily share a function on list which can be used to convert all old terms in existing Org-mode files). The problem are not every-day users, but if one is not using org-mode not using for some time, it might be difficult to figure out what has changed - also, I wou't remember in three years time, that these things have changed, and run into problems when trying to open an old org-file (in the case of literae programming not unlikely). But I also see your point - Eric. And the problem is, someday, you will have to remove such functionality (allowing a smooth transition, thanks to declaring to use an obsolete feature set). So, IMHO, better do it now, once for all... ... if you have: a function which checks if these files do include the old / deprecated keywords, and inform the user? See my modified version of Eric's function: #+begin_src emacs-lisp ;; warn about deprecated feature from version 7.7 (add-hook 'org-mode-hook (lambda () (save-excursion (goto-char (point-min)) (when (re-search-forward (org-make-options-regexp '(BABEL)) nil t) (display-warning 'org-babel (format This file contains a \#+BABEL:\ line.) :warning) #+end_src My changes: - warning in its own window, to be sure to see it (because it's soo easy for the message in the echo area to be overwritten by others, if you have many hooks doing many things); - no error when match not found. This function could even, in this case here, suggest to do the replacing. This function could be over time extended, whenever in-compatible changes become necessary - it would be a kind of an org-to-org converter or org-version-checker? See this draft: #+begin_src emacs-lisp (defun my/org-propertyze-babel-line () Play me as many times as needed... (interactive) ;; (goto-char (point-min)) ;; (search-forward #+BABEL:) (search-forward-regexp :) (delete-backward-char 2) (insert \n#+PROPERTY: )) #+end_src To be used, in its current state, with point placed just after the #+BABEL: keyword. Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Eric, Eric Schulte wrote: #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) which would look horrible in one line and a nightmare to edit. I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified rather than simply replacing the value. Perhaps this could be done with a variable like org-accumulating-properties which could hold a list of those properties which should accumulate values rather than overwriting them. 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: SVNVERSION=(vc-working-revision (buffer-file-name)), #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))), #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13), FWIW I would like to have a similar extender for #+TBLFM: lines. Actually this choice may be my preferred solution. What do you think? I think that makes sense. While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. Best regards, Seb -- Sebastien Vauban
[O] Suddenly, my timestamps get localized!
Hi all, when I insert a new timestame, I now get 2011-10-25 Di while it used to be 2011-10-25 Tue until very recently. (Di is Dienstag which is German for Tuesday). I've briefly grepped the org source code, but I cannot see any localization there. What's going on? I even have no glue how org/emacs (correctly) guesses that I'm German. My locale is en_US.UTF-8... Bye, Tassilo
Re: [O] Suddenly, my timestamps get localized!
Hi Tassilo, Tassilo Horn wrote: when I insert a new timestame, I now get 2011-10-25 Di while it used to be 2011-10-25 Tue until very recently. (Di is Dienstag which is German for Tuesday). I've briefly grepped the org source code, but I cannot see any localization there. What's going on? I even have no glue how org/emacs (correctly) guesses that I'm German. My locale is en_US.UTF-8... Found in my .emacs: #+begin_src emacs-lisp ;; system locale to use for formatting time values (e.g., timestamps in ;; Org mode files) (setq system-time-locale C) ;; en_US.utf8 did not work for the weekday in the agenda! #+end_src Now, the question is: why did it change on your machine? New Emacs, new Cygwin (if on Windows)? See discussion http://cygwin.com/ml/cygwin/2011-09/msg6.html on Cygwin (though I don't know what to understand from it...). Best regards, Seb -- Sebastien Vauban
Re: [O] Suddenly, my timestamps get localized!
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Tassilo, Tassilo Horn wrote: when I insert a new timestame, I now get 2011-10-25 Di while it used to be 2011-10-25 Tue until very recently. (Di is Dienstag which is German for Tuesday). I've briefly grepped the org source code, but I cannot see any localization there. What's going on? I even have no glue how org/emacs (correctly) guesses that I'm German. My locale is en_US.UTF-8... Found in my .emacs: #+begin_src emacs-lisp ;; system locale to use for formatting time values (e.g., timestamps in ;; Org mode files) (setq system-time-locale C) ;; en_US.utf8 did not work for the weekday in the agenda! #+end_src Now, the question is: why did it change on your machine? New Emacs, new Cygwin (if on Windows)? See discussion http://cygwin.com/ml/cygwin/2011-09/msg6.html on Cygwin (though I don't know what to understand from it...). Or updated localisation catalogs. I've also put (setq system-time-locale C) in my .emacs-en because that is the only sane settings if you move your org-files between accounts in any kind of way. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Tue, Oct 25, 2011 at 11:35 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Eric, Eric Schulte wrote: #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) which would look horrible in one line and a nightmare to edit. I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified rather than simply replacing the value. Perhaps this could be done with a variable like org-accumulating-properties which could hold a list of those properties which should accumulate values rather than overwriting them. 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: SVNVERSION=(vc-working-revision (buffer-file-name)), #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))), #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13), FWIW I would like to have a similar extender for #+TBLFM: lines. Actually this choice may be my preferred solution. What do you think? I think that makes sense. While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. I am not Eric, but I think that would be a good idea. Bu there needs to be a way of specifying more then one property, either by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: . Thinking about it, it should be possible without the +: #+PROPERTY[R]: tangle no #+PROPERTY[R]: export both The more I see it, the more I like it - also the [] 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] Suddenly, my timestamps get localized!
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Sebastien, What's going on? I even have no glue how org/emacs (correctly) guesses that I'm German. My locale is en_US.UTF-8... Found in my .emacs: #+begin_src emacs-lisp ;; system locale to use for formatting time values (e.g., timestamps in ;; Org mode files) (setq system-time-locale C) ;; en_US.utf8 did not work for the weekday in the agenda! #+end_src Ok, that does the trick. It was nil before. And (setq system-time-locale (getenv LANG)) resulting in en_US.utf8 seems to work as well. What did not work for you in the agenda? Now, the question is: why did it change on your machine? New Emacs, new Cygwin (if on Windows)? I'm on GNU/Linux and update my emacs bzr and org git checkouts about thrice a week. All I can say is that a week ago, timestamps where English (or at least I didn't notice). Bye, Tassilo
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi Rainer, Rainer M Krug wrote: While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. I am not Eric, but I think that would be a good idea. Thanks for your comments. Bu there needs to be a way of specifying more then one property, either by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: . Thinking about it, it should be possible without the +: #+PROPERTY[R]: tangle no #+PROPERTY[R]: export both Yes, no need for a + here, as the lines do target different properties (in this case, tangle and export). The more I see it, the more I like it - also the [] In fact, the lines without any language specification would be, at least semantically, equivalent to something like this: #+PROPERTY[*]:tangle no #+PROPERTY[*]:eval never Best regards, Seb -- Sebastien Vauban
Re: [O] Suddenly, my timestamps get localized!
Hi Tassilo, Tassilo Horn wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: What's going on? I even have no glue how org/emacs (correctly) guesses that I'm German. My locale is en_US.UTF-8... Found in my .emacs: #+begin_src emacs-lisp ;; system locale to use for formatting time values (e.g., timestamps in ;; Org mode files) (setq system-time-locale C) ;; en_US.utf8 did not work for the weekday in the agenda! #+end_src Ok, that does the trick. It was nil before. Good to know! And (setq system-time-locale (getenv LANG)) resulting in en_US.utf8 seems to work as well. What did not work for you in the agenda? When I wrote (months ago) did not work, I meant: I got French weekdays in my agenda (Lun. for Monday, Mar., Mer., etc. -- even on 4 characters). I could retry... but I don't have UTF8 specified in my LANG var. I should do add it, I guess. Best regards, Seb PS- I'm on Windows XP, with a win32 binary from FSF. -- Sebastien Vauban
Re: [O] Suddenly, my timestamps get localized!
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: And (setq system-time-locale (getenv LANG)) resulting in en_US.utf8 seems to work as well. What did not work for you in the agenda? When I wrote (months ago) did not work, I meant: I got French weekdays in my agenda (Lun. for Monday, Mar., Mer., etc. -- even on 4 characters). With system-time-locale nil, I got Mo, Di, Mi,... only in the timestamps while the agenda was still Monday, Tuesday, Wednesday... Bye, Tassilo
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Tue, Oct 25, 2011 at 12:31 PM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Hi Rainer, Rainer M Krug wrote: While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. I am not Eric, but I think that would be a good idea. Thanks for your comments. Bu there needs to be a way of specifying more then one property, either by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: . Thinking about it, it should be possible without the +: #+PROPERTY[R]: tangle no #+PROPERTY[R]: export both Yes, no need for a + here, as the lines do target different properties (in this case, tangle and export). The more I see it, the more I like it - also the [] In fact, the lines without any language specification would be, at least semantically, equivalent to something like this: #+PROPERTY[*]:tangle no #+PROPERTY[*]:eval never So #+PROPERTY followed by square brackets, means properties for source blocks of a given language, and [*] is the default and can be omitted. Two ideas: [R,sh], i.e. specifying a list of languages in the brackets could be useful, as well as wildcards like [dit*]? The latter less usefull, but for consistency? Additionally: it would be nice, if one could define a set of properties, and then recall them for certain blocks. e.g: #+PROPERTY[R:set1]: tangle no #+PROPERTY[R:set1]: eval never #+PROPERTY[R:set2]: tangle yes #+PROPERTY[R:set2]: export both #+src_begin R :set set1 cat(1) #+end would have the first set of properties (tangle no and eval never), where #+src_begin R :set set2 cat(1) #+end would have the second set of properties (tangle no and eval never) Might be a good addition? 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
[O] Bug in export to LaTex: Lists with source code blocks
Hello,
there is a bug when exporting to LaTeX if there is a source code block
inside a list.
I have a file with the following contents:
#+begin_org
#+TITLE: Lists mit Source-Blocks
#+AUTHOR:thomas.ho...@gmx.de
#+EMAIL: Thomas Holst
#+DATE: 25.10.2011
#+LANGUAGE: en
#+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:{} -:t f:t *:t :t
#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
* A heading
1. First Item
#+begin_src perl
print First example:\n;
#+end_src
Text in first item.
2. Second Item
#+begin_src perl
print Second example:\n;
#+end_src
Text in second item.
#+end_org
The exportet LaTeX file contains the following:
#+begin_src latex
% [ ... snip ... ]
\begin{document}
% [ ... snip ... ]
\begin{enumerate}
\item First Item
\lstset{language=Perl}
\begin{lstlisting}
print First example:\n;
\end{lstlisting}
\end{enumerate}
%^^
Text in first item.
\begin{enumerate}
%
\item Second Item
\lstset{language=Perl}
\begin{lstlisting}
print Second example:\n;
\end{lstlisting}
\end{enumerate}
%^^
Text in second item.
ORG-LIST-END-MARKER
%^^
\end{document}
#+end_src
The enumerate environment is ended after the source code block and
started before the next item again. There is a line saying
'ORG-LIST-END-MARKER' which should not be there. I marked the
relevant lines with comments.
This happens with:
(emacs-version)
GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-09-19 on 3249CTO on WinXP
(org-version)
Org-mode version 7.7 (release_7.7.396.gfaaa)
Tested with a minimal setup file:
#+begin_src emacs-lisp
;;
-
;; set path to local org repo
;;
-
(add-to-list 'load-path ~/git/org-mode/lisp)
;; pfad zu contib/lisp
(add-to-list 'load-path ~/git/org-mode/contrib/lisp)
(add-to-list 'load-path ~/git/org-mode/contrib/babel/lisp)
(require 'org-install)
(require 'org-latex)
(find-file ~/emacs/Testing/ListsSCB.org)
(org-export-as-latex-to-buffer 3)
#+end_src
: emacs -Q --eval (load-file \~/emacs/Testing/start-exp-test.el\)
In Org-mode version 7.7 (release_7.7) the bug does not exist.
'git bisect' showed that the bug was introduced by:
commit 707897c25c8f2412a31d5f47bc2c201c5bcf8d1d
Author: Nick Dokos n...@dokosmarshall.org
Date: Fri Aug 19 05:02:57 2011 -0400
Eliminate extra newline(s) after example or src block.
Signed-off-by: Nick Dokos n...@dokosmarshall.org
--
Bis neulich ...
Thomas
[O] [Bug] Return on description link
Hi! See the attached org-file for more information. Hitting return on a link in a description list does not follow the link but insert newline. I have org-return-follows-link set to t. Regards, Max link.org Description: Binary data
[O] HTML export, TODO keyword face
Hi,
I set up org todo keyword faces like so:
(setq org-todo-keyword-faces
'((FAIL . org-warning)
(MISSING . org-warning)
))
But at html export, the keywords are green because they are done
states. So additionally I have to set :
(setq org-export-html-style-extra
style type=\text/css\
!--/*--![CDATA[/*!--*/
.FAIL { color: red; }
.MISSING { color: red; }
/*]]*/--
/style)
I think the default style should be what is set in org-todo-keyword-faces.
[O] Bug?: handling asterisks * in HTML export
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Emacs : GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO Package: Org-mode version 7.7 2429e834915a11b58c85f18488976e274d6ce387 I found two errors of org while handling asterisks * in HTML export. I don't think this is a bug, but I think it is worth to report. I wrote my test.org file (see below). Then I tried to html-export a subtree: C-c @ C-c C-e B and I got the errors: (wrong-type-argument stringp nil) or (args-out-of-range [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil] -1) Before trying to reporduce, please, remember to change the tag :noexport: e.g. adding a letter :noexporti: ne eksporti ;-) so you can export only a section of the file. The complete debug trace is under the heading * backtraces. The culprit sholud be string-match(^ *QUOTE\\( +\\|[ ]*$\\) nil). cheers, Giovanni test.org -- -*- mode: org; -*- * [2011-10-25 mar] test list asterisk hello ** 1 * without space :noexport: * hello ** test 2 ** without space :noexport: ** I found a bug? an error? ** test 3: * with a space :noexporti: * newline * backtraces ** backtrace 1 Debugger entered--Lisp error: (wrong-type-argument stringp nil) string-match(^ *QUOTE\\( +\\|[ ]*$\\) nil) (if (string-match quote-re0 txt) (setq txt (replace-match t t txt))) (cond ((string-match \\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ ]*$ line) (setq level ... txt ...) (if ... ...) (if ... ...) (setq first-heading-pos ...) (org-html-level-start level txt umax ... head-count opt-plist) (when ... ... ... ...)) ((and org-export-with-tables ...) (when ... ...) (setq table-buffer ... table-orig-buffer ...) (when ... ... ... ...)) (t (when ... ...) (when ... ... ...) (if ... ...) (when org-export-with-footnotes ... ...) (cond ... ...) (let ... ...) (insert line \n))) (catch (quote nextline) (when (and inquote ...) (insert /pre\n) (org-open-par) (setq inquote nil)) (when inquote (insert ... \n) (throw ... nil)) (when (and org-export-with-fixed-width ...) (when ... ... ... ...) (insert ... \n) (when ... ... ... ...) (throw ... nil)) (when (and ... ...) (let ... ... ... ... ...) (throw ... nil)) (when (equal ORG-BLOCKQUOTE-START line) (org-close-par-maybe) (insert blockquote\n) (org-open-par) (throw ... nil)) (when (equal ORG-BLOCKQUOTE-END line) (org-close-par-maybe) (insert \n/blockquote\n) (org-open-par) (throw ... nil)) (when (equal ORG-VERSE-START line) (org-close-par-maybe) (insert \np class=\verse\\n) (setq org-par-open t) (setq inverse t) (throw ... nil)) (when (equal ORG-VERSE-END line) (insert /p\n) (setq org-par-open nil) (org-open-par) (setq inverse nil) (throw ... nil)) (when (equal ORG-CENTER-START line) (org-close-par-maybe) (insert \ndiv style=\text-align: center\) (org-open-par) (throw ... nil)) (when (equal ORG-CENTER-END line) (org-close-par-maybe) (insert \n/div) (org-open-par) (throw ... nil)) (run-hooks (quote org-export-html-after-blockquotes-hook)) (when inverse (let ... ... ...)) (setq start 0) (while (string-match ?\\([^]*\\)?\\((INVISIBLE)\\)?[ ]*\n? line start) (cond ... ... ... ...)) (setq line (org-html-handle-time-stamps line)) (or (string-match org-table-hline-regexp line) (string-match ^[ ]*\\([+]-\\||[ ]\\)[-+ |]*[+|][ ]*$ line) (setq line ...)) (setq line (org-html-handle-links line opt-plist)) (if (and org-todo-line-regexp ... ...) (setq line ...)) (when org-export-with-footnotes (setq start 0) (while ... ...)) (cond (... ... ... ... ... ... ...) (... ... ... ...) (t ... ... ... ... ... ... ...))) (while (setq line (pop lines) origline line) (catch (quote nextline) (when ... ... ... ...) (when inquote ... ...) (when ... ... ... ... ...) (when ... ... ...) (when ... ... ... ... ...) (when ... ... ... ... ...) (when ... ... ... ... ... ...) (when ... ... ... ... ... ...) (when ... ... ... ... ...) (when ... ... ... ... ...) (run-hooks ...) (when inverse ...) (setq start 0) (while ... ...) (setq line ...) (or ... ... ...) (setq line ...) (if ... ...) (when org-export-with-footnotes ... ...) (cond ... ... ...))) (let ((case-fold-search nil) (org-odd-levels-only odd)) (mapc (lambda ... ...) org-export-plist-vars) (setq umax (if arg ... org-export-headline-levels)) (setq umax-toc (if ... ... umax)) (unless body-only (insert ...) (when ... ...) (insert ... \nh1 class=\title\ title /h1\n)) (if (and org-export-with-toc ...) (progn ... ... ... ... ... ... ...)) (setq head-count 0) (org-init-section-numbers) (org-open-par) (while (setq line ... origline line) (catch ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
Re: [O] FYI: Org mode testing framework, Emacs 23 and 22
On Mon, Oct 24, 2011 at 7:12 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: For my information, why do you need to test that 2 suites don't run at the same time? They only write to temp buffers, no? Can they conflict? If they do conflict and only one set of tests should run at a time, shouldn't the second set of tests be queued up so it runs when the first is complete? If this isn't done, I could see a situation where at least one commit remains untested until the next commit. my $0.02; Brian
[O] Querying Org-contacts with lbdb (e.g. for mutt)
Hi!
I want to share a solution that allows lbdb[1] queries return
Org-contacts[2] email addresses. The solution is done by Russell
Adams who encouraged me to post it here because he did only mention
it in [3] but did not post the results yet. I took Russells solution
and modified it to be of more general use and added a few comments
in the Perl script.
If you are interested in my personal approach for managing contact
information with Org-contacts, please refer to [4].
The set up requires three things:
1. configuration file .lbdbrc (usually in ~ or ~/.lbdb/)
- add «m_orgcontact» to the variable «METHODS»
- add «$HOME/.lbdb/modules» to the variable «MODULES_PATH»
,[ example lines ]
| METHODS=m_orgcontact m_muttalias m_inmail
| MODULES_PATH=/usr/lib/lbdb $HOME/.lbdb/modules
`
2. ~/.lbdb/modules/m_orgcontact (just a small interface to connect
lbdb to the script)
,[ m_orgcontact ]
| #!/bin/sh
|
| m_orgcontact_query()
| {
| ${HOME}/.lbdb/modules/orgcontact.pl $1
| }
| #end
`
3. ~/.lbdb/modules/orgcontact.pl (the actual script that queries)
See below footnotes for the whole script.
1. http://www.spinnaker.de/lbdb/
2. http://julien.danjou.info/org-contacts.html
3. http://lists.gnu.org/archive/html/emacs-orgmode/2011-02/msg00459.html
4. http://article.gmane.org/gmane.emacs.orgmode/47478/
~/.lbdb/modules/orgcontact.pl --
#!/usr/bin/env perl
use strict;
use warnings;
## FIXXME: error handling when no argument is given (though unlikely)
$/=\n*; ## split between Org-mode headings (i.e. newline followed by
asterisk)
## the path to your Org-contacts file:
my $orgmodefile=$ENV{HOME} . /share/all/org-mode/contacts.org;
open(MYFILE,$orgmodefile);
my @rawcontacts = MYFILE; ## read in whole contact file, heading by heading
close(MYFILE);
$/=\n; ## reset split string to newlines (only)
foreach (@rawcontacts) {
if ( $_ =~ m/$ARGV[0]/i ){ ## ARGV[0] is the query string
my $name;
foreach (split(\n,$_)) { ## go through it line by line
# The first line consists of the contact name (followed by tag(s))
unless (defined $name) {
$name = $_;
$name =~ s/^\*+\s(.*)\s+:\S+:.*$/$1/g; ## extract string between
asterisks and tags
}
# if (m/^\s+:.*EMAIL.*:/i) {
if (m/^:EMAIL:/i) { ## for each property «:EMAIL:» print out result
my $email = $_;
$email =~ s/^:\S+:\s+(\S+)/$1/g;
$email =~ s/\s*$//;
printf(%s\t%s\t(Org)\n, $email, $name);
}
}
}
}
-
--
Karl Voit
Re: [O] Blocked tasks also dimmed in export?
Just bumping this in case anyone can help me fix it - I'd really like the tasks to be greyed out in an export. Thanks, Gez On 13 October 2011 12:57, Gez sule...@gmail.com wrote: I use org-agenda-dim-blocked-tasks to keep track of tasks that have no current todo's, but in my exported html agenda view (C-c a e) which I share via dropbox, there is unfortunately no dimming. Is there a way to preserve the grey face in html export? Gez
Re: [O] BUG: footnote conflicts with code export to pdf
Nick Dokos nicholas.do...@hp.com writes:
zwz zhangwe...@gmail.com wrote:
Then you modify it:
#+begin_src org
* test
#+BEGIN_SRC c
void main(){
int a[5];
}
#+END_SRC
#+end
It says org-export-latex-preprocess: Wrong type argument: stringp,
nil
when you try to export the file.
You didn't say what version of org you are using. I cannot reproduce
it
in Org-mode version 7.7 (release_7.7.416.g93bd.dirty)
Nick
I am using org-mode 7.7-1 (installed by pacman on Archlinux).
Just for future reference: this version does not exist in git, so it
doesn't tell me much. What does M-x org-version say? That's the
important thing (of course, the Archlinux people might have modified it
but it's still the best bet when reporting versions).
Be that as it may, I checked that release_7.7 had the problem, so I
tried
a bisection and found that the fix is in the following commit:
,
| commit c3631aae7e68565978433cad8c4a2b286e91dfac
| Author: Nicolas Goaziou n.goaz...@gmail.com
| Date: Sat Jul 30 12:38:06 2011 +0200
|
| org-footnote: prevent LaTeX export from catching footnotes in protect
environment
|
| * lisp/org-footnote.el (org-footnote-in-valid-context-p): check
| `org-protected' property before allowing to match a footnote.
| (org-footnote-at-reference-p): remove an obsolete test. It's now done
| in the previous function.
`
Nick
Thanks for pointing this out.
Now I get the latest org, and it is smooth.
Re: [O] Patch: Mark org-diary-class as obsolete and skip entries on holidays in org-class
Hi Rüdiger, On Oct 10, 2011, at 9:15 PM, Rüdiger Sonderfeld wrote: Hello, I wrote two small patches. The first one marks org-diary-class as obsolete (according to its documentation it is deprecated). The second one is a patch for org-class. It changes org-class to skip entries that are on holidays. The first is accepted. The second I have modified. If any of SKIP-WEEKS is the symbol `holidays', then holidays will be skipped. Thanks! - Carsten Maybe the second change should be made optional. Regards, Rüdiger P.S. I have signed the FSF papers. 0001-Mark-org-diary-class-as-obsolete-use-org-class.patch0002-org-class-Skip-entries-on-holidays.patch
Re: [O] Bug?: handling asterisks * in HTML export
I have the same problem this org file creates the bug: * headline * test this doesn't: * headline - test Best, Rainer Am 25.10.2011 15:21, schrieb Giovanni Ridolfi: Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Emacs : GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO Package: Org-mode version 7.7 2429e834915a11b58c85f18488976e274d6ce387 I found two errors of org while handling asterisks * in HTML export. I don't think this is a bug, but I think it is worth to report. I wrote my test.org file (see below). Then I tried to html-export a subtree: C-c @ C-c C-e B and I got the errors: (wrong-type-argument stringp nil) or (args-out-of-range [nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil] -1) Before trying to reporduce, please, remember to change the tag :noexport: e.g. adding a letter :noexporti: ne eksporti ;-) so you can export only a section of the file. The complete debug trace is under the heading * backtraces. The culprit sholud be string-match(^ *QUOTE\\( +\\|[ ]*$\\) nil). cheers, Giovanni test.org -- -*- mode: org; -*- * [2011-10-25 mar] test list asterisk hello ** 1 * without space :noexport: * hello ** test 2 ** without space :noexport: ** I found a bug? an error? ** test 3: * with a space :noexporti: * newline * backtraces ** backtrace 1 Debugger entered--Lisp error: (wrong-type-argument stringp nil) string-match(^ *QUOTE\\( +\\|[ ]*$\\) nil) (if (string-match quote-re0 txt) (setq txt (replace-match t t txt))) (cond ((string-match \\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ ]*$ line) (setq level ... txt ...) (if ... ...) (if ... ...) (setq first-heading-pos ...) (org-html-level-start level txt umax ... head-count opt-plist) (when ... ... ... ...)) ((and org-export-with-tables ...) (when ... ...) (setq table-buffer ... table-orig-buffer ...) (when ... ... ... ...)) (t (when ... ...) (when ... ... ...) (if ... ...) (when org-export-with-footnotes ... ...) (cond ... ...) (let ... ...) (insert line \n))) (catch (quote nextline) (when (and inquote ...) (insert /pre\n) (org-open-par) (setq inquote nil)) (when inquote (insert ... \n) (throw ... nil)) (when (and org-export-with-fixed-width ...) (when ... ... ... ...) (insert ... \n) (when ... ... ... ...) (throw ... nil)) (when (and ... ...) (let ... ... ... ... ...) (throw ... nil)) (when (equal ORG-BLOCKQUOTE-START line) (org-close-par-maybe) (insert blockquote\n) (org-open-par) (throw ... nil)) (when (equal ORG-BLOCKQUOTE-END line) (org-close-par-maybe) (insert \n/blockquote\n) (org-open-par) (throw ... nil)) (when (equal ORG-VERSE-START line) (org-close-par-maybe) (insert \np class=\verse\\n) (setq org-par-open t) (setq inverse t) (throw ... nil)) (when (equal ORG-VERSE-END line) (insert /p\n) (setq org-par-open nil) (org-open-par) (setq inverse nil) (throw ... nil)) (when (equal ORG-CENTER-START line) (org-close-par-maybe) (insert \ndiv style=\text-align: center\) (org-open-par) (throw ... nil)) (when (equal ORG-CENTER-END line) (org-close-par-maybe) (insert \n/div) (org-open-par) (throw ... nil)) (run-hooks (quote org-export-html-after-blockquotes-hook)) (when inverse (let ... ... ...)) (setq start 0) (while (string-match ?\\([^]*\\)?\\((INVISIBLE)\\)?[ ]*\n? line start) (cond ... ... ... ...)) (setq line (org-html-handle-time-stamps line)) (or (string-match org-table-hline-regexp line) (string-match ^[ ]*\\([+]-\\||[ ]\\)[-+ |]*[+|][ ]*$ line) (setq line ...)) (setq line (org-html-handle-links line opt-plist)) (if (and org-todo-line-regexp ... ...) (setq line ...)) (when org-export-with-footnotes (setq start 0) (while ... ...)) (cond (... ... ... ... ... ... ...) (... ... ... ...) (t ... ... ... ... ... ... ...))) (while (setq line (pop lines) origline line) (catch (quote nextline) (when ... ... ... ...) (when inquote ... ...) (when ... ... ... ... ...) (when ... ... ...) (when ... ... ... ... ...) (when ... ... ... ... ...) (when ... ... ... ... ... ...) (when ... ... ... ... ... ...) (when ... ... ... ... ...) (when ... ... ... ... ...) (run-hooks ...) (when inverse ...) (setq start 0) (while ... ...) (setq line ...) (or ... ... ...) (setq line ...) (if ... ...) (when org-export-with-footnotes ... ...) (cond ... ... ...))) (let ((case-fold-search nil) (org-odd-levels-only odd)) (mapc (lambda ... ...) org-export-plist-vars) (setq umax (if arg ... org-export-headline-levels)) (setq umax-toc (if ... ... umax)) (unless body-only (insert ...) (when ... ...) (insert ... \nh1 class=\title\ title
Re: [O] Bug?: handling asterisks * in HTML export
Hello, Giovanni Ridolfi giovanni.rido...@yahoo.it writes: I found two errors of org while handling asterisks * in HTML export. I don't think this is a bug, but I think it is worth to report. I've pushed a fix in master. Could you confirm that it is working? Please note that single stars, in part 1 and 3, won't appear in the HTML output as they are correctly interpreted as empty list items. Thanks for reporting this. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Standardized code block keywords
Alright, I've tallied up the results and we have the following (with full voting information below [1]). Call lines | call | 13 | It seems unanimous that remote code block calls should use the #+call: syntax moving forward. Data and result names | (name results) | 3 | | name | 2 | | (data results) | 2 | | (object results) | 1 | | data | 1 | | object | 1 | The Data and result name lines were less straightforward, but I think the best solution which also seems to be the majority opinion will be to allow #+name: lines to be used to name results, and in the case of results of un-named code blocks a #+results: line will be used. It will also be necessary to allow usage of #+tblname: for as long as this syntax is used to name tables for Org-mode spreadsheet formulas. Code block names | srcname | 5 | | name| 4 | | source | 3 | | src | 1 | Surprisingly (to me) srcname is the winner here, but luckily I haven't yet voted, and although I would have though #+source: would have been the winner I like the simplicity of using #+name: for named code blocks as well as named data. So I'll vote for #+name: here making it a tie, and I'll also take tie-breaking powers upon myself giving #+name: the win. I hope to put together an implementation of this change soon. Cheers -- Eric Footnotes: [1] ** eliminate synonyms #+tblname: code-block-names | source | dye | | srcname | dokos | | srcname | moe | | srcname | vauban| | srcname | wagner| | name| goaziou | | srcname | thorsten | | source | rosenfeld | | name| bausch| | source | malone| | name| moreira | | name| fraga | | src | krug | #+tblname: call-lines | call | dye | | call | dokos | | call | moe | | call | vauban| | call | wagner| | call | goaziou | | call | thorsten | | call | rosenfeld | | call | bausch| | call | malone| | call | moreira | | call | fraga | | call | krug | #+tblname: data-names | object | dye | | (data results) | wagner| | name | goaziou | | (data results) | rosenfeld | | (name results) | bausch| | data | malone| | name | moreira | | (name results) | fraga | | (object results) | krug | | (name results) | vauban| #+begin_src emacs-lisp :var data=call-lines (mapcar (lambda (el) (list (car el) (cdr el))) (reduce (lambda (acc vote) (cons (cons vote (+ 1 (or (cdr (assoc vote acc)) 0))) (remove-if (lambda (pair) (equal (car pair) vote)) acc))) (mapcar #'car data) :initial-value ())) #+end_src Call lines | call | 13 | Data and result names | (name results) | 3 | | name | 2 | | (data results) | 2 | | (object results) | 1 | | data | 1 | | object | 1 | Code block names | srcname | 5 | | name| 4 | | source | 3 | | src | 1 | -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug?: handling asterisks * in HTML export
Am 25.10.2011 16:42, schrieb Nicolas Goaziou: Hello, Giovanni Ridolfi giovanni.rido...@yahoo.it writes: I found two errors of org while handling asterisks * in HTML export. I don't think this is a bug, but I think it is worth to report. I've pushed a fix in master. Could you confirm that it is working? Please note that single stars, in part 1 and 3, won't appear in the HTML output as they are correctly interpreted as empty list items. Thanks for reporting this. Regards, Hi Nicolas, works as expected. Thanks a lot! Rainer
Re: [O] [RFC] Standardized code block keywords
Surprisingly (to me) srcname is the winner here, but luckily I haven't yet voted, and although I would have though #+source: would have been the winner I like the simplicity of using #+name: for named code blocks as well as named data. Ditto -- it just wasn't on the table yet when I cast my vote. Christian
Re: [O] [RFC] Standardized code block keywords
Eric Schulte schulte.e...@gmail.com wrote: Surprisingly (to me) srcname is the winner here, but luckily I haven't yet voted, and although I would have though #+source: would have been the winner I like the simplicity of using #+name: for named code blocks as well as named data. So I'll vote for #+name: here making it a tie, and I'll also take tie-breaking powers upon myself giving #+name: the win. This is going to cost you, Schulte! It's not going to go down that easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the NFL and the MLB: an outrage I tell you! An affront to the democratic rules some of us cherish! We'll fight to the death! Who's with me? Nobody? Dang - I'll go back to sleep then.
Re: [O] Bug?: handling asterisks * in HTML export
Nicolas Goaziou n.goaz...@gmail.com writes: I found two errors of org while handling asterisks * in HTML export. I don't think this is a bug, but I think it is worth to report. I've pushed a fix in master. Could you confirm that it is working? yes it works, thanks, Giovanni
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
I think that makes sense. While thinking about all of this, and working in real-life documents, I just came back to a suggestion which I made some time ago. It goes about this enhancement: Would it be possible to specify buffer-wide language specific header arguments? Yes, this is already possible. You can customize the org-babel-default-header-args:lang variable (where lang is the source name) as a file local variable. That is, be able to say: In this document, I want to: - tangle all my .sql chunks, but no other; - eval all the elisp chunks with query, but no other. Something we could write quite easily along the lines: #+PROPERTY: tangle no #+PROPERTY: eval never #+PROPERTY[SQL]: tangle yes #+PROPERTY[EMACS-LISP]: eval query (the syntax used here is just a draft sample!) I do not think we can customize the PROPERTY syntax as is exists outside of Babel. The goal here was to piggy-back on top of rather than co-opt regular Org-mode syntax. Best -- Eric What do you think about this feature? If you feel it can be something interesting to have, this is surely to incorporate in the current syntax debate. If not... never mind. Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [RFC] Standardized code block keywords
Then maybe #+results for (anonymous) results only, but #+name for anything else from [1] and [3]. This seems like a reasonable approach. Wasn't there a concept of linking a results block to its originiating source block by some id and we need a place to put the checksum in. Not that I recall. So I see some arguments for treating results special. But for the others I do not see pressing arguments against a common name at the moment. However, I'd like to ask, what happens, if one refers to a name of a source block where data is expected, does it then refer to the results produced by that source block? How are such situations handeled at the moment? Try it out, but be ready to press C-g, because I would guess that it results in an infinite loop. In other words: is there any type checking? Type checking could be facilitated by using different words, although I think that is not neccessary, because there are other means to distinguish the type of a block (look at the next line in the buffer). No, there is no type checking in Babel, and the mere thought of implementing such a features leaves me exhausted. I think it is safe to allow users to shoot themselves in the foot if they so please. Cheers -- Eric Daniel -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [RFC] Standardized code block keywords
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Surprisingly (to me) srcname is the winner here, but luckily I haven't yet voted, and although I would have though #+source: would have been the winner I like the simplicity of using #+name: for named code blocks as well as named data. So I'll vote for #+name: here making it a tie, and I'll also take tie-breaking powers upon myself giving #+name: the win. This is going to cost you, Schulte! It's not going to go down that easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the NFL and the MLB: an outrage I tell you! An affront to the democratic rules some of us cherish! We'll fight to the death! Who's with me? +1 #+name mj
Re: [O] [RFC] Standardized code block keywords
Martyn Jago martyn.j...@btinternet.com writes: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Surprisingly (to me) srcname is the winner here, but luckily I haven't yet voted, and although I would have though #+source: would have been the winner I like the simplicity of using #+name: for named code blocks as well as named data. So I'll vote for #+name: here making it a tie, and I'll also take tie-breaking powers upon myself giving #+name: the win. This is going to cost you, Schulte! It's not going to go down that easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the NFL and the MLB: an outrage I tell you! An affront to the democratic rules some of us cherish! We'll fight to the death! Who's with me? Ha! Well at least SCOTUS should be on my side, as they seem to have no problem giving some people more freedom than others. +1 #+name Well thank goodness, even if I can't put my own thumb on the scale it seems I can advertise enough to sway voters to my cause. :) Cheers -- Eric mj -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] feature suggestion: apply datetime prompt magic to selected region
On 24 October 2011 08:00, Bastien b...@altern.org wrote: Hi Brian, suvayu ali fatkasuvayu+li...@gmail.com writes: Ah I see it now, you want the org-timestamp command to work on a region. Maybe you can write your own function with lisp if you are doing this too often. Should be quite simple to try. Please check `org-loop-over-headlines-in-active-region' from latest git repo and see if using `org-schedule' in the region does what you want. We can actually implement this for `org-timestamp' as well, if relevant. Thanks, -- Bastien Hi Bastien, Thanks for replying and giving this your attention. Various people upthread convinced me that my feature request wasn't really worth it. (I do hope it didn't cost you too much time!) So, I am content to drop it here :-) That said, it seems only right to respond and let you know how things sit. Feel free to let it die. Unless I misunderstood, that does not do what I had in mind. With a fresh git pull I invoked emacs with emacs --no-site-file -l minimalorgtestdotemacs test.org where minimalorgtestdotemacs reads: (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-cc 'org-capture) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (transient-mark-mode 1) (setq org-loop-over-headlines-in-active-region t) and test.org reads: * test 2003-01-26 Versions: Org-mode version 7.7 (release_7.7.464.g679a0) GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian If I have point and mark on either end of 2003-01-26 and invoke M-x org-schedule, nothing occurs. By analogy with my original request, what was desired was for the region to automatically get fed to the datetime prompt and thus for the test subtree to acquire the scheduled date of 2003-01-26 without further intervention. So, thanks again for the attention to the suggestion. I'm more than happy to let it rest here. Best, Brian vdB
Re: [O] Patch: Mark org-diary-class as obsolete and skip entries on holidays in org-class
Hi Carsten, On Tue, 25 Oct 2011 16:08:43 +0200, Carsten Dominik carsten.domi...@gmail.com wrote: The first is accepted. The second I have modified. If any of SKIP-WEEKS is the symbol `holidays', then holidays will be skipped. That sounds good. Thank you. Regards, Rüdiger
Re: [O] [RFC] Standardized code block keywords
Eric Schulte schulte.e...@gmail.com wrote: Martyn Jago martyn.j...@btinternet.com writes: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Surprisingly (to me) srcname is the winner here, but luckily I haven't yet voted, and although I would have though #+source: would have been the winner I like the simplicity of using #+name: for named code blocks as well as named data. So I'll vote for #+name: here making it a tie, and I'll also take tie-breaking powers upon myself giving #+name: the win. This is going to cost you, Schulte! It's not going to go down that easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the NFL and the MLB: an outrage I tell you! An affront to the democratic rules some of us cherish! We'll fight to the death! Who's with me? Ha! Well at least SCOTUS should be on my side, as they seem to have no problem giving some people more freedom than others. Indeed - but what about the NFL? I bet they have more integrity. On second thought... +1 #+name Back stabber! Well thank goodness, even if I can't put my own thumb on the scale it seems I can advertise enough to sway voters to my cause. :) Bribery and Corruption - what is the world coming to? Cheers -- Eric mj -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] FYI: Org mode testing framework, Emacs 23 and 22
Hi Brian Wightman midlife...@wightmanfam.org writes: On Mon, Oct 24, 2011 at 7:12 AM, Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: For my information, why do you need to test that 2 suites don't run at the same time? They only write to temp buffers, no? Can they conflict? If they do conflict and only one set of tests should run at a time, shouldn't the second set of tests be queued up so it runs when the first is complete? If this isn't done, I could see a situation where at least one commit remains untested until the next commit. my $0.02; Brian I would think it would make sense to ensure the newly committed code also builds correctly (including info), and why not test back to Emacs 22 also (since that is how this thread came about)? I have set up something similar, and doing all this takes less than 1 minute on my machine. Incidentally, I added info on running tests on Emacs 22 and 23 to Worg at http://orgmode.org/worg/org-tests/index.html Best, Martyn
Re: [O] notify, when something to do
Ha, the XMPP idea really appeals to me, endless possibilities :D Thanks for sharing. On Mon, Oct 24, 2011 at 10:01 AM, Christopher Allan Webber cweb...@dustycloud.org wrote: Hey Peter, I also do appointments with orgmode.. I have it hooked up so that it sends me messages via XMPP/Jabber. Possibly useful to you: http://dustycloud.org/blog/2010/11/21/emacs-appointment-notifications-via-xmpp pmli...@free.fr (Peter Münster) writes: Hello, I would like to be notified[1], when a todo item enters the warning period, scheduled time, or deadline. I can imagine writing a function, that executes every 5 minutes, that scans all agenda files calling `org-get-[scheduled,deadline]-time', but I hope, that there is already something, that I can use more easily. TIA for any help, Peter Footnotes: [1] For notifying, I'll use an external program, for example notify-send, because the emacs window is not always visible.
[O] org-capture template property completion
I am an emacs novice attempting to use an org-capture template. The
manual indicates completion is available while expanding %^{prompt}.
Can one get completion on %^{prop}p for a property? I tried the same
syntax for prompt and that did not work.
David
[O] [babel] Announcing ob-picolisp.el
Hi list, with help and substancial input from Eric (Schulte) I added a new language to org-babel, the minimal lisp dialect picolisp [thanks to Eric!]. You can download the ob-picolisp.el file here: https://github.com/tj64/ob-picolisp Here is the README text as a little introduction to picolisp: ,--- | README | | This Emacs library enables the use of PicoLisp in the multi-language | programming framework Org-Babel | (http://orgmode.org/worg/org-contrib/babel/index.html). | | PicoLisp is a minimal yet fascinating lisp dialect and a highly | productive application framework for web-based client-server | applications on top of object-oriented databases. A good way to learn | PicoLisp is to first read Paul Grahams essay The hundred year | language (http://www.paulgraham.com/hundred.html) and then study the | various documents and essays published in the PicoLisp wiki | (http://picolisp.com/5000/-2.html). PicoLisp is included in some | GNU/Linux Distributions, and can be downloaded here: | http://software-lab.de/down.html. It ships with a picolisp-mode and a | inferior-picolisp-mode for Emacs (to be found in the /lib/el/ | directory). | | Although it might seem more natural to use Emacs Lisp for most | Lisp-based programming tasks inside Org-Mode (http://orgmode.org/), an | Emacs library written in Emacs Lisp, PicoLisp has at least two | outstanding features that make it a valuable addition to Org-Babel: | | PicoLisp _is_ an object-oriented database with a Prolog-based query | language implemented in PicoLisp (Pilog). Database objects are | first-class members of the language. | | PicoLisp is an extremely productive framework for the development | of interactive web-applications (on top of a database). `--- cheers -- Thorsten
[O] Bug: tags search in org-sparse-tree is broken
Hi, The tags search for org-sparse-tree seems to be broken. With a minimal setup, C-c / m match RET doesn't perform a tags search. I bisected the problem to this commit. dfcb6faef11a2439b56b18a6289803361d402130 is the first bad commit commit dfcb6faef11a2439b56b18a6289803361d402130 Author: Nicolas Goaziou n.goaz...@gmail.com Date: Thu Aug 25 01:58:29 2011 +0200 Provide more consistent regexps for headlines HTH -- Suvayu Open source is the future. It sets us free.
Re: [O] Bill-of-materials
Hi Bastien, I'm trying to push my changes to the Worg repo, but it asks me for my repo.or.cz's password. This confuses me, as the repo.or.cz states that they don't use password. One of the changes I've made is to host the org-bom.el on github (better than pastebin). https://github.com/Frozenlock/Org-Bill-of-materials I've also corrected a bug which caused a mixed section when more than one was specified per row. Have a nice day! On Sat, Oct 22, 2011 at 4:26 AM, Bastien b...@altern.org wrote: Hi Frozenlock, Frozenlock frozenl...@gmail.com writes: This is a much better version of the little add-on I've written: Bill-of-materials (org-bom.el) Thanks -- I add this to Worg/org-contrib/index.org. Please check the description when it goes online and improve it if necessary. 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 I used http://pastebin.com/raw.php?i=K11QpQ6Q as the location for getting the raw code -- hopefully pastebin will keep this URL valid. The tutorial is included with it, but here is an eye-friendly version: http://frozenlock.wordpress.com/2011/10/20/bom-bills-of-materials/ Thanks! -- Bastien
Re: [O] [RFC] Standardized code block keywords
However, I'd like to ask, what happens, if one refers to a name of a source block where data is expected, does it then refer to the results produced by that source block? How are such situations handeled at the moment? Try it out, but be ready to press C-g, because I would guess that it results in an infinite loop. Isn't it possible to refer to the results of a code block as input data for another? I thought it was. If not currently then at least I suppose that it will be in the future. The new syntax should be ready for that. Daniel
Re: [O] Bill-of-materials
Hi Frozenlock, Frozenlock frozenl...@gmail.com writes: I'm trying to push my changes to the Worg repo, but it asks me for my repo.or.cz's password. This confuses me, as the repo.or.cz states that they don't use password. You need to register as a user on repo.or.cz: http://repo.or.cz/reguser.cgi then write to Matt Lundin mdl @ imapmail.org telling him what your username is, he will add you to the Worg project so that you can push changes directly. One of the changes I've made is to host the org-bom.el on github (better than pastebin). https://github.com/Frozenlock/Org-Bill-of-materials Indeed! I've also corrected a bug which caused a mixed section when more than one was specified per row. Thanks -- looking for the changes on Worg. Also, I will have a closer look at org-bom.el before adding it to contrib/. If there are any users of org-bom.el, please share your feedback! Best, -- Bastien
Re: [O] [RFC] Standardized code block keywords
Am Dienstag 25 Oktober 2011, 19:21:22 schrieb Nick Dokos: Eric Schulte schulte.e...@gmail.com wrote: Martyn Jago martyn.j...@btinternet.com writes: Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Surprisingly (to me) srcname is the winner here, but luckily I haven't yet voted, and although I would have though #+source: would have been the winner I like the simplicity of using #+name: for named code blocks as well as named data. So I'll vote for #+name: here making it a tie, and I'll also take tie-breaking powers upon myself giving #+name: the win. This is going to cost you, Schulte! It's not going to go down that easily. I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the NFL and the MLB: an outrage I tell you! An affront to the democratic rules some of us cherish! We'll fight to the death! Who's with me? Ha! Well at least SCOTUS should be on my side, as they seem to have no problem giving some people more freedom than others. Indeed - but what about the NFL? I bet they have more integrity. On second thought... +1 #+name Back stabber! Oops, I didn't want to split the community. Be nice to each other. Well thank goodness, even if I can't put my own thumb on the scale it seems I can advertise enough to sway voters to my cause. :) Bribery and Corruption - what is the world coming to? Cheers -- Eric mj
