Re: [O] M-RET and C-RET
Hello, Michael Brand michael.ch.br...@gmail.com writes: With #+begin_src org ,*** abc ,*** def ,- ghi ,- jkl #+end_src M-RET on j inserts a line above but I expected it below. If I want a line above I would move the point to - before doing M-RET like I do on a heading where I move to the first * to get the insert above. Point isn't on j. It's either before or after it. In your case, point is before j. And using M-RET on an item before its body start will result in creating an item before it. This is done so to avoid splitting counters or check-boxes. You shouldn't compare lists and headlines behaviour, they don't have the same constraints. Changing to the behavior expected by me would make it possible to add a new list item below the last one in a list (a very frequent task) Go to the end of the last item, and use M-RET. If it is really frequent, the following function will do what you want: #+begin_src emacs-lisp (defun org-insert-item-at-end (optional arg) Insert a new list item at the end of the current list. When optional argument ARG is non-nil, add a check-box to the item. (interactive P) (let ((itemp (org-in-item-p))) (unless itemp (error Not in an item)) (goto-char (org-in-item-p)) (let* ((struct (org-list-struct)) (prevs (org-list-prevs-alist struct))) ;; Move to the end of the last item in list, before any white ;; space, and insert item there. (goto-char (org-list-get-item-end (org-list-get-last-item itemp struct prevs) struct)) (skip-chars-backward \r\t\n) ;; Repair list. (setq struct (org-list-insert-item (point) struct prevs arg)) (org-list-write-struct struct (org-list-parents-alist struct)) ;; Take care of check-boxes count, if needed. (when arg (org-update-checkbox-count-maybe)) ;; Position point at body's start. (looking-at org-list-full-item-re) (goto-char (match-end 0) #+end_src I configured it to nil for headline and item only to be able to insert a new list item below the current with M-RET where I am forced to be on or at right of k which by default splits which I want only in very rare cases. If you want to split lines only on very rare occasions, why is it a problem to set `org-M-RET-may-split-line' to nil? And one should not be invited to avoid M-RET and edit lists with - and TAB as illustrated in the thread org-list-indent-offset only works partially: http://thread.gmane.org/gmane.emacs.orgmode/47954 Which part of the thread are you referring to? I see no suggestion about avoiding usage of M-RET. Regards, -- Nicolas Goaziou
Re: [O] [bug] void-function org-babel-named-data-regexp-for-name
Hi Seb, The `org-babel-named-data-regexp-for-name' function is called by ob-ref.el which *does* require ob.el. I'm not sure why this require isn't being run on your system. Could you try a make clean and then restarting Emacs and see if the problem was caused by old inconsistent .elc files? Thanks, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hello, When exporting a document containing calls to code blocks located in my LOB (here: `vc-indicator'), I have -- with latest Org version -- a new problem (I mean, it wasn't there a couple of days ago): Debugger entered--Lisp error: (void-function org-babel-named-data-regexp-for-name) It seems to me that there is a missing (require 'ob) in org-export (?). Loading manually `ob.el' does solve that particular problem. Best regards, Seb #+begin_src text Debugger entered--Lisp error: (void-function org-babel-named-data-regexp-for-name) (org-babel-named-data-regexp-for-name ref) (let ((src-rx (org-babel-named-src-block-regexp-for-name ref)) (res-rx (org-babel-named-data-regexp-for-name ref))) (or (re-search-forward src-rx nil t) (re-search-forward res-rx nil t) (setq id (org-babel-ref-goto-headline-id ref)) (setq lob-info (cdr (assoc (intern ref) org-babel-library-of-babel) (if (let ((src-rx (org-babel-named-src-block-regexp-for-name ref)) (res-rx (org-babel-named-data-regexp-for-name ref))) (or (re-search-forward src-rx nil t) (re-search-forward res-rx nil t) (setq id (org-babel-ref-goto-headline-id ref)) (setq lob-info (cdr (assoc (intern ref) org-babel-library-of-babel) (unless (or lob-info id) (goto-char (match-beginning 0))) (error reference '%s' not found in this buffer ref)) (save-restriction (widen) (goto-char (point-min)) (if (let ((src-rx (org-babel-named-src-block-regexp-for-name ref)) (res-rx (org-babel-named-data-regexp-for-name ref))) (or (re-search-forward src-rx nil t) (re-search-forward res-rx nil t) (setq id (org-babel-ref-goto-headline-id ref)) (setq lob-info (cdr (assoc (intern ref) org-babel-library-of-babel) (unless (or lob-info id) (goto-char (match-beginning 0))) (error reference '%s' not found in this buffer ref)) (cond (lob-info (setq type (quote lob))) (id (setq type (quote id))) ((and (looking-at org-babel-src-name-regexp) (save-excursion (forward-line 1) (or (looking-at org-babel-src-block-regexp) (looking-at org-babel-multi-line-header-regexp (setq type (quote source-block))) (t (while (not (setq type (org-babel-ref-at-ref-p))) (forward-line 1) (beginning-of-line) (if (or (= (point) (point-min)) (= (point) (point-max))) (error reference not found) (let ((params (append args (quote ((:results . silent)) (setq result (case type (results-line (org-babel-read-result)) (table (org-babel-read-table)) (list (org-babel-read-list)) (file (org-babel-read-link)) (source-block (org-babel-execute-src-block nil nil (if org-babel-update-intermediate nil params))) (lob (org-babel-execute-src-block nil lob-info params)) (id (org-babel-ref-headline-body) (if (symbolp result) (format %S result) (if (and index (listp result)) (org-babel-ref-index-list index result) result))) (let ((case-fold-search t) type args new-refere new-header-args new-referent result lob-info split-file split-ref index index-row index-col id) (when (and (string-match \\[\\([^\\[]+\\)\\]$ ref) (let ((str (substring ref 0 (match-beginning 0 (= (org-count 40 str) (org-count 41 str (setq index (match-string 1 ref)) (setq ref (substring ref 0 (match-beginning 0 (when (string-match ^\\(.+?\\)\\(\\[\\(.*\\)\\]\\|\\(\\)\\)(\\(.*\\))$ ref) (setq new-refere (match-string 1 ref)) (setq new-header-args (match-string 3 ref)) (setq new-referent (match-string 5 ref)) (when ( (length new-refere) 0) (when ( (length new-referent) 0) (setq args (mapcar (lambda (ref) (cons :var ref)) (org-babel-ref-split-args new-referent (when ( (length new-header-args) 0) (setq args (append (org-babel-parse-header-arguments new-header-args) args))) (setq ref new-refere))) (when (string-match ^\\(.+\\):\\(.+\\)$ ref) (setq split-file (match-string 1 ref)) (setq split-ref (match-string 2 ref)) (find-file split-file) (setq ref split-ref)) (save-restriction (widen) (goto-char (point-min)) (if (let ((src-rx (org-babel-named-src-block-regexp-for-name ref)) (res-rx (org-babel-named-data-regexp-for-name ref))) (or (re-search-forward src-rx nil t) (re-search-forward res-rx nil t) (setq id (org-babel-ref-goto-headline-id ref)) (setq lob-info (cdr (assoc ... org-babel-library-of-babel) (unless (or lob-info id) (goto-char (match-beginning 0))) (error reference '%s' not found in this buffer ref)) (cond (lob-info (setq type (quote lob))) (id (setq type (quote id))) ((and (looking-at org-babel-src-name-regexp) (save-excursion (forward-line 1) (or (looking-at org-babel-src-block-regexp) (looking-at
Re: [O] [bug] Code blocks (in a LOB) are not ingested anymore
Hi Seb, I *do* get a single code block loaded when running your ECM. What values does the `org-babel-src-name-regexp' variable have on your system? If it is not equal to ^[ ]*#\\+name:[]* then my guess is that you have old versions of Org-mode defining this variable, and these definitions are not updated when you load the newer Org-mode over-top. Please see the bottom of the following commit message for an explanation and a workaround. http://orgmode.org/w/?p=org-mode.git;a=commit;h=7e93b90f8816346a16ad49cee22870b17c05b211 If you are using the development version of Emacs24 this problem will be resolved after Org-mode pushes to Emacs in the coming weeks. Best -- Eric Sebastien Vauban wxhgmqzgw...@spammotel.com writes: #+TITLE: ECM for code blocks not being ingested anymore #+DATE: 2011-12-02 #+PROPERTY: eval yes * Overview Ingesting a LOB file does not load its code blocks anymore -- as if the file was empty, or if there were no code blocks at all in it! * Test case ** How many blocks? There is 1 block in this file. That's what this code block should answer. #+begin_src emacs-lisp :exports results (org-babel-lob-ingest (buffer-file-name)) #+end_src #+results: : 0 While a couple of days ago, it correctly answered 1, now it answers 0 as you can see/test. ** Block to be found #+name: defvar-now #+begin_src sql DECLARE @now smalldatetime -- implementation is not important in this context! #+end_src Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] M-RET and C-RET
Hi Nicolas I try to argue for some supposed common Org user that likes it simple like me, is used to the behavior of M-RET and C-RET on headings and is about to learn to use lists and M-RET but doesn't want to know about org-M-RET-may-split-line that he prefers to leave on its default as typical for trying out step by step. I don't argue for myself, I had already found out and understand how to configure and how to do. But if M-RET with point on j would insert _below_: 1) it would be simpler to understand (from the user view, not necessarily for implementation but often there too) because also M-RET with point on d inserts already below 2) it would make possible to add a new list item below the last with M-RET already with the default org-M-RET-may-split-line or even emacs -Q I can not see anything that could not be done with this that can be done now. What am I missing? On Sat, Dec 3, 2011 at 11:24, Nicolas Goaziou n.goaz...@gmail.com wrote: Michael Brand michael.ch.br...@gmail.com writes: With #+begin_src org ,*** abc ,*** def ,- ghi ,- jkl #+end_src M-RET on j inserts a line above but I expected it below. If I want a line above I would move the point to - before doing M-RET like I do on a heading where I move to the first * to get the insert above. Point isn't on j. It's either before or after it. In your case, point is before j. When I wrote this I exactly asked myself which of these two perspectives I want to choose: - point is before 'j': - in some cases it leaves the question open if it means just before or rather between something (e. g. beginning of line) and j - sounds to me like referring to an edit cursor shape that is a bar between characters which is not the cursor shape of all users - point is on 'j': - can refer to the position of point in the buffer like with C-x = or the Emacs Lisp functions point and some point-* - can refer to the character address or fsetpos() position in the corresponding file - can refer to an edit cursor shape that is a box on a character (the only possibility for some terminal emulators and the default for the windowed GNU Emacs on Linux, Mac OS X and Solaris) I hope that this explains my preference for the second. And using M-RET on an item before its body start will result in creating an item before it. This is done so to avoid splitting counters or check-boxes. I don't understand this. What would be wrong with - point on -: M-RET inserts above - point on [X]: M-RET inserts below (consistent with point on TODO on a line *** TODO def) - point on j: M-RET inserts below - point on kl: M-RET splits (default config) when considering the line - [X] jkl? You shouldn't compare lists and headlines behaviour, they don't have the same constraints. Nevertheless, wouldn't point 1) at the top add more consistency? I configured it to nil for headline and item only to be able to insert a new list item below the current with M-RET where I am forced to be on or at right of k which by default splits which I want only in very rare cases. If you want to split lines only on very rare occasions, why is it a problem to set `org-M-RET-may-split-line' to nil? Not a problem for me, trying to simplify for others, see at the top and also its point 2). And one should not be invited to avoid M-RET and edit lists with - and TAB as illustrated in the thread org-list-indent-offset only works partially: http://thread.gmane.org/gmane.emacs.orgmode/47954 Which part of the thread are you referring to? I see no suggestion about avoiding usage of M-RET. I'm sorry for the confusion and hope it becomes clearer this way: As illustrated in the thread org-list-indent-offset only works partially here http://thread.gmane.org/gmane.emacs.orgmode/47954 one should not insert list items by editing with - and TAB but use M-RET. What I meant with the invitation to avoid M-RET is that until I understood better a few weeks ago I used - and TAB to insert a new item below the current line because more or less intentionally I left org-M-RET-may-split-line at its default and because - M-RET did not let me add a new list item below the last, and the relation to org-M-RET-may-split-line was not obvious for me - when I wanted to insert a new list item below the current line I didn't like (maybe silly, I know) to move to the next item to be able to use M-RET to insert above from there Michael
[O] Generating clock table for arbitrary date range
Is there any way to specify a start and end date for the :block property of a clock table? Lately I have often found myself submitting an invoice based upon my clock report on Friday evening, only to be called frantically on Saturday and having to put in additional hours (this should sound familiar to many programmers :)), which I then need to attribute to next week's clock table to be submitted on the following invoice. Is there an easy way to do this? -- A. Ryan Reynolds
Re: [O] Generating clock table for arbitrary date range
A. Ryan Reynolds a.ryan.reynolds at gmail.com writes: Is there any way to specify a start and end date for the :block property of a clock table? Lately I have often found myself submitting an invoice based upon my clock report on Friday evening, only to be called frantically on Saturday and having to put in additional hours (this should sound familiar to many programmers :)), which I then need to attribute to next week's clock table to be submitted on the following invoice. Is there an easy way to do this? -- A. Ryan Reynolds I'm not sure how this solves problem you describe, but see the tstart and tend options for clocktables: http://orgmode.org/manual/The-clock-table.html#The-clock-table For example: #+begin: clocktable :tstart 2011-10-27 Tue :tend 2011-11-22 Tue #+end The above is for a dynamic block in the document. If you're talking about clocktables in agenda I assume the way to modify is to change the period of the agenda view.
Re: [O] Generating clock table for arbitrary date range
Aha! Thank you. That works nicely. I had known about :tstart and :tend but I misunderstood their purpose.
Re: [O] new ikiwiki export plugin for org
On Fri, Dec 02, 2011 at 10:23:11PM -0700, Chris Gray wrote: I've created a new export plugin for org-mode files for the ikiwiki wiki compiler. It's in a very preliminary state at https://github.com/chrismgray/ikiwiki-org-plugin Oh very nice. I saw your questions on the topic in #ikiwiki recently, and I'm very interested to follow your progress. How are you handling page directives and other parts of the ikiwiki specific markup in org? I'm a longtime user of ikiwiki but I'm pretty comfortable with Markdown, so I typically don't really feel like I need to make my ikiwiki's use non-markdown formats. In the past when I've tried this, my feeling is that while ikiwiki *should* be pretty agnostic with regard to markup language, it isn't really. Which is to say that ikiwiki creates links between pages by inserting raw HTML into markdown pages and then hands the page off to the markdown interpreter. Which is great, but means that the other processors have to handle inline html in the same way as markdown, or links break. You can turn off the inter-page linking, but when you do that ikiwiki ends up doing very little. I've also not found a way to selectively turn the link processing plugin on or off... Cheers, tychoish -- tycho(ish) @ ga...@tychoish.com http://tychoish.com/ don't get it right, get it written -- james thurber pgpO1oFT2vb3h.pgp Description: PGP signature
Re: [O] new ikiwiki export plugin for org
On Sat, 3 Dec 2011 23:59:51 -0500, tycho garen ga...@tychoish.com wrote: On Fri, Dec 02, 2011 at 10:23:11PM -0700, Chris Gray wrote: I've created a new export plugin for org-mode files for the ikiwiki wiki compiler. It's in a very preliminary state at https://github.com/chrismgray/ikiwiki-org-plugin Oh very nice. I saw your questions on the topic in #ikiwiki recently, and I'm very interested to follow your progress. How are you handling page directives and other parts of the ikiwiki specific markup in org? Those generally get stripped out before the org files are htmlized. Also, I am using a mix of markdown and org -- only the posts are in org, and they don't have any ikiwiki specific markup beyond a tags directive. I'm a longtime user of ikiwiki but I'm pretty comfortable with Markdown, so I typically don't really feel like I need to make my ikiwiki's use non-markdown formats. In the past when I've tried this, my feeling is that while ikiwiki *should* be pretty agnostic with regard to markup language, it isn't really. Which is to say that ikiwiki creates links between pages by inserting raw HTML into markdown pages and then hands the page off to the markdown interpreter. Which is great, but means that the other processors have to handle inline html in the same way as markdown, or links break. You can turn off the inter-page linking, but when you do that ikiwiki ends up doing very little. I've also not found a way to selectively turn the link processing plugin on or off... Right. My current thinking is that I'll use the scan and linkify hooks to do the link processing myself, so that raw html isn't inserted. Basically, the idea is to transform links into org links and let org do the transformation to html. We'll see if it works. Cheers, Chris
[O] Different face for org-table fields with formulas
Has anyone hacked up the use of using a different face for org-table fields with formulas. This would be useful for quickly realizing what are inputs and outputs in a org spreadsheet. Currently I do this by adding the formatting ;~%.4f~ to my formulas. But it would be nicer if this was a settable property. Thanks! Dov
