Re: [O] [RFC] Standardized code block keywords
On Tue, Oct 25, 2011 at 8:52 AM, Rainer M Krug 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 c
Re: [O] [RFC] Standardized code block keywords
On Fri, Oct 21, 2011 at 6:24 PM, Eric Schulte wrote:
> > 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), MS
Re: [O] How to include comments on export? org-exp-blocks.el?
>> I think the comment blocks are better handled as special blocks instead >> of org-exp-blocks. > That may very well be true. If only - , From org-export-preprocess-string | ;; Call the hook | (run-hooks 'org-export-preprocess-hook) | | ;; Remove comment environment and comment subtrees | (org-export-remove-comment-blocks-and-subtrees) | | ;; Blockquotes, verse, and center | (org-export-mark-blockquote-verse-center) | (run-hooks 'org-export-preprocess-after-blockquote-hook) ` Before it hits the blockquote hook the comment block gets removed. Now there is a reason why the hook is hooking up to org-export-preprocess-hook. While complaining of plethora of hooks, I was mainly complaining from this standpoint. This example also illustrates my frustration as an implementer well. Apart from other things, there is this - Oh! yet another hook that I need to take care of and cater to in org-odt.el. Also software behaviour is counter-intuitive. This prevents one from asserting a mental model with any confidence without diving in to the code. >> ps: I think number of blocks and hooks in Org reflect number of people >> that worked on it :-) >> -- >> > > Well, I don't mind a plethora of hooks: they enable things that wouldn't > be possible otherwise (and they are even documented and easily findable > because of uniform naming: either the M-x org--hook trick which works > because of the uniform naming [fn:1] or the Worg (?) page that Carsten > pointed to some time ago[fn:2]). org-exp.el is a sequential assembly line. If one rearranges logic in it even a bit - with no regard to the hook boundaries for example - the whole export process goes for a toss. And when you name a hook afterblockquote hook you can't move it before the blockquote can you? > As for org-exp-blocks, two out of the three areas of its application, as > discussed in the commentary, are deprecated: only comment remains. But > contrary to your (tongue-in-cheek) remark, Eric Schulte seems to be > single-handedly responsible for all of the block stuff :-) I do see some aspects of current day babel in the deprecated blocks. May be Carsten and various users from the distant past had a hand in various "standard but useful" hooks like verse, quote, center, comments etc. > Nick > > Footnotes: > > [fn:1] Note to future maintainers: don't ever name a hook anything other than > org-foo-bar-hook or else :-) > > [fn:2] I prefer the first to the second because I can do it right in emacs: no > need to go look up URLs and use inferior tools. > > --
Re: [O] How to include comments on export? org-exp-blocks.el?
Jambunathan K wrote: > > > So I tried > > > > (add-hook 'org-export-preprocess-hook (function > > org-export-blocks-preprocess)) > > > > and I get the comment in the HTML output. > > Is it valid a valid xhtml? > I have no idea: I was mainly interested in how to make org-exp-blocks to work (for some value of "work") and although I looked at the HTML, I didn't check it. > M-x nxml-mode > C-c C-n (assumming rng validation is on) > > I find that it suffers from the same problem that cropped up wrt special > blocks. See this thread > http://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00046.html > > I think the comment blocks are better handled as special blocks instead > of org-exp-blocks. > That may very well be true. > ps: I think number of blocks and hooks in Org reflect number of people > that worked on it :-) > -- > Well, I don't mind a plethora of hooks: they enable things that wouldn't be possible otherwise (and they are even documented and easily findable because of uniform naming: either the M-x org--hook trick which works because of the uniform naming [fn:1] or the Worg (?) page that Carsten pointed to some time ago[fn:2]). As for org-exp-blocks, two out of the three areas of its application, as discussed in the commentary, are deprecated: only comment remains. But contrary to your (tongue-in-cheek) remark, Eric Schulte seems to be single-handedly responsible for all of the block stuff :-) Nick Footnotes: [fn:1] Note to future maintainers: don't ever name a hook anything other than org-foo-bar-hook or else :-) [fn:2] I prefer the first to the second because I can do it right in emacs: no need to go look up URLs and use inferior tools.
Re: [O] How to include comments on export? org-exp-blocks.el?
> So I tried > > (add-hook 'org-export-preprocess-hook (function org-export-blocks-preprocess)) > > and I get the comment in the HTML output. Is it valid a valid xhtml? M-x nxml-mode C-c C-n (assumming rng validation is on) I find that it suffers from the same problem that cropped up wrt special blocks. See this thread http://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00046.html I think the comment blocks are better handled as special blocks instead of org-exp-blocks. ps: I think number of blocks and hooks in Org reflect number of people that worked on it :-) --
Re: [O] Source blocks for tiny snippets
Nick Dokos writes: > Thorsten wrote: > >> ... >> There is, e.g., the shortcut >> >> ,--- >> | > `--- >> >> to insert a code-block, but its somehow underdocumented - I don't >> remember, where I read about it, and don't find it in the manual >> anymore. >> > > It is documented in sec. 15.2, "Easy Templates", of > the org manual (along with how to add your own): > > (info "(org) Easy Templates") > I was not aware this existed. I've just updated the manual to point to this feature when the code block syntax is introduced. Thanks -- Eric > > Nick > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [RFC] Standardized code block keywords
"Sebastien Vauban" 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 -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Org-mode Standardized Code Block Keywords
Chris Malone writes: > Hi Eric, > > Here is the CSV output from google moderator - do with it what you wish: > Great, I've incorporated this output. Thanks -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] How to include comments on export? org-exp-blocks.el?
Herbert Sitz writes: > I'm trying to see if there is a way to include comments on export, to show up > as > something like the comments boxes you see in MS Word. What is your target format? Is it org->odt->doc. If yes, then currently there is no support for annotations/comments. It is doable. I did some investigation of it in some other context - inline tasks. You can see some of my notes here: See the Footnotes section of - http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00357.html
Re: [O] Byte compiler warnings
A few warnings from Emacs 23.2.1 here: Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-C.el at Mon Oct 24 18:20:36 2011 Entering directory `/home/xx/.emacs.d/elpa/org-20111024/' Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-calc.el at Mon Oct 24 18:20:36 2011 In end of data: ob-calc.el:105:1:Warning: the following functions are not known to be defined: calc-store-into, calc-recall, math-evaluate-expr Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-shen.el at Mon Oct 24 18:20:38 2011 In org-babel-execute:shen: ob-shen.el:68:32:Warning: reference to free variable `result-params' ob-shen.el:72:19:Warning: reference to free variable `result' Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-agenda.el at Mon Oct 24 18:20:39 2011 In org-agenda-list: org-agenda.el:3555:26:Warning: `org-agenda-ndays' is an obsolete variable (as of Emacs 24.1); use `org-agenda-span' instead. In org-agenda-get-todos: org-agenda.el:4596:26:Warning: reference to free variable `org-heading-keyword-regexp-format' In org-agenda-goto-today: org-agenda.el:6410:59:Warning: `org-agenda-ndays' is an obsolete variable (as of Emacs 24.1); use `org-agenda-span' instead. In org-agenda-reset-view: org-agenda.el:6495:36:Warning: `org-agenda-ndays' is an obsolete variable (as of Emacs 24.1); use `org-agenda-span' instead. Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-colview.el at Mon Oct 24 18:20:41 2011 In org-columns-capture-view: org-colview.el:1155:32:Warning: reference to free variable `org-heading-keyword-regexp-format' org-colview.el:1160:33:Warning: reference to free variable `org-heading-regexp' Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-compat.el at Mon Oct 24 18:20:41 2011 In org-find-library-name: org-compat.el:341:14:Warning: find-library called with 3 arguments, but accepts only 1 Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-docbook.el at Mon Oct 24 18:20:41 2011 In org-export-as-docbook: org-docbook.el:502:31:Warning: reference to free variable `org-heading-keyword-regexp-format' Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-exp.el at Mon Oct 24 18:20:42 2011 In org-export-protect-quoted-subtrees: org-exp.el:1641:31:Warning: reference to free variable `org-heading-keyword-regexp-format' In org-export-remove-comment-blocks-and-subtrees: org-exp.el:1936:31:Warning: reference to free variable `org-heading-keyword-regexp-format' Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-html.el at Mon Oct 24 18:20:47 2011 In org-export-as-html: org-html.el:1179:31:Warning: reference to free variable `org-heading-keyword-regexp-format'
[O] Fixed!! (was: Re: Problem with org-startup-indented)
On Tue, 18 Oct 2011 17:30:17 +, Andrei Jirnyi wrote: > There is a major issue with org-indent-mode under org-mode 7.7 > (downloaded today with Emacs PPM, dated 2011-10-18) and Emacs 23.2. It seems that whatever the issue was, it could be fixed by either: - forcing byte-compile on the downloaded package files by smth like M-: (byte-recompile-directory "~/.emacs.d/elpa/org/[whatever]" 0 t) - loading the newer (2011-10-24) distribution. Perhaps it was related to the ELPA thing somehow. I wonder if the order of compilation might matter for org-mode? I think in the comments in package.el someone mentions that it currently has issues with tramp because tramp requires a specific order of compilation. --aj
Re: [O] How to include comments on export? org-exp-blocks.el?
Herbert Sitz wrote: > Herbert Sitz gmail.com> writes: > > > > > Can someone give an example of how org-exp-blocks (or anything else) could > > be > > used to export comment blocks as graphic notes in the text? > > > > Just to add a bit. I do have the following line in my .emacs: > > (require 'org-exp-blocks) > > and I have a comment like this in my document: > > --- sample text below -- > * Heading one > text here > #+begin_comment > some comment text here > #+end_comment > * Heading two > --- sample text above -- > > > When I export it the headings and text print out but the comment doesn't. I > assume I need to do something more than have the 'require' for org-exp-blocks > in > my .emacs but I can't figure out what it is. > The only documentation there is seems to be in the file itself (and that is not very complete). If you get it working, you might want to submit a patch to improve the documentation. Two hints from org-exp-blocks.el: , | ;; This is a utility for pre-processing blocks in org files before | ;; export using the `org-export-preprocess-hook'. It can be used for ` , | (defun org-export-blocks-preprocess () | "Export all blocks according to the `org-export-blocks' block export alist. | Does not export block types specified in specified in BLOCKS | which defaults to the value of `org-export-blocks-witheld'." ` So I tried --8<---cut here---start->8--- (add-hook 'org-export-preprocess-hook (function org-export-blocks-preprocess)) --8<---cut here---end--->8--- and I get the comment in the HTML output. Nick
Re: [O] How to include comments on export? org-exp-blocks.el?
Herbert Sitz gmail.com> writes: > > Can someone give an example of how org-exp-blocks (or anything else) could be > used to export comment blocks as graphic notes in the text? > Just to add a bit. I do have the following line in my .emacs: (require 'org-exp-blocks) and I have a comment like this in my document: --- sample text below -- * Heading one text here #+begin_comment some comment text here #+end_comment * Heading two --- sample text above -- When I export it the headings and text print out but the comment doesn't. I assume I need to do something more than have the 'require' for org-exp-blocks in my .emacs but I can't figure out what it is. -- Herb
Re: [O] [PATCH] Agenda: Allow filter list without category in org-agenda-to-appt
Hi Peter, pmli...@free.fr (Peter Münster) writes: > Here the output of "git format-patch master". I hope it's correct, it > was my first git-commit... Yes, that's great -- I could save the patch and apply it without problem. http://orgmode.org/w/?p=org-mode.git;a=commit;h=68ffb7a7cc8cd99a49cf69491edba85988f8229c Next time, you can simply attach the patch instead of inserting it in the body of the email. That way it gets caught by the patchwork. Also, you can send it directly to the list, but the way to achieve this depends on your mail client. For example: http://andrewprice.me.uk/weblog/entry/generating-patch-emails-with-git Thanks! HTH, -- Bastien
[O] How to include comments on export? org-exp-blocks.el?
I'm trying to see if there is a way to include comments on export, to show up as something like the comments boxes you see in MS Word. I see Eric Schulte did some work on this and that somehow it ended up (I think) as part of what you could do using the org-exp-blocks addon. But I'm not sure how you actually use it. Can someone give an example of how org-exp-blocks (or anything else) could be used to export comment blocks as graphic notes in the text? Thanks, Herb
[O] [PATCH] Agenda: Allow filter list without category in org-agenda-to-appt
Hello, Here the output of "git format-patch master". I hope it's correct, it was my first git-commit... --8<---cut here---start->8--- >From 82da273bb0884347762e883786b334302ad3f0cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Peter=20M=C3=BCnster?= Date: Mon, 24 Oct 2011 20:52:45 +0200 Subject: [PATCH] Agenda: Allow filter list without category in org-agenda-to-appt * lisp/org-agenda.el (org-agenda-to-appt): Make sure filter-items are strings before calling `string-match'. Now it's possible to use (org-agenda-to-appt t '((headline "string"))). TINYCHANGE --- lisp/org-agenda.el | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 24ead18..0b4c07b 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8489,10 +8489,12 @@ details and examples." (and (stringp filter) (string-match filter evt)) (and (functionp filter) (funcall filter x)) (and (listp filter) - (or (string-match - (cadr (assoc 'category filter)) cat) - (string-match - (cadr (assoc 'headline filter)) evt)) + (let ((cat-filter (cadr (assoc 'category filter))) +(evt-filter (cadr (assoc 'headline filter +(or (and (stringp cat-filter) + (string-match cat-filter cat)) +(and (stringp evt-filter) + (string-match evt-filter evt ;; FIXME: Shall we remove text-properties for the appt text? ;; (setq evt (set-text-properties 0 (length evt) nil evt)) (when (and ok tod) -- 1.7.3.4 --8<---cut here---end--->8--- -- Peter
Re: [O] BUG: footnote conflicts with code export to pdf
zwz 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
| 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
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
I didn't check the list for 3 days and this thread became a little hard to follow. So, forgive me if I'm "answering" the wrong E-Mail. I liked Christian's idea of using a single "var" property to tell babel which regular properties it should use as variables (ignoring any variable not defined). This would be enough for my use cases. On the other hand, some way to append values to a property, such as using some special keyword as I have suggested, could be a better solution in order to keep consistence if people want this feature for non-babel related properties. -- Darlan At Sat, 22 Oct 2011 09:53:25 -0600, Eric Schulte wrote: > > Darlan Cavalcante Moreira writes: > > > It's excellent that now babel understands multiple values in the "var" > > property (I was one of the people that wanted this), but "There Is One More > > Thing". > > > > Would it be feasible to inherit variables from parent sub-trees? > > Effectively, I'd like to append new values in lower level sub-trees, but > > AFAIK setting the var property in a sub-tree will still replace the value > > set in the parent sub-tree. > > > > Currently every new property specification entirely replaced previous > specifications with the same name. > > > > > That is, in the example below the level-2 sub-trees would not have the foo > > variable passed to babel. > > * Code with foo > > :PROPERTIES: > > :var: foo=1 > > :END: > > > > ** Code only with bar > >:PROPERTIES: > >:var: bar=2 > >:END: > >src_block > > ** Code only with baz > >:PROPERTIES: > >:var: baz=3 > >:END: > >src_block > > > > Maybe a special keyword, such as "inherit" (or "append") could be used to > > incorporate variables defined in the parent sub-tree, such that the example > > would become > > * Code with foo > > :PROPERTIES: > > :var: foo=1 > > :END: > > > > ** Code with foo and bar > >:PROPERTIES: > >:var: bar=2, inherit > >:END: > >src_block > > ** Code with foo and baz > >:PROPERTIES: > >:var: baz=3, inherit > >:END: > >src_block > > > > This should not affect global variables and "inherit" would inherit > > variables defined only in the parent sub-tree (unless it also contains the > > inherit keyword). > > > > As a use case scenario, suppose I need to perform simulations for a few > > different scenarios, each with small variations. This would allow me to > > define common variables for a scenario in a higher level sub-tree and more > > specific variables in the lower level sub-trees. > > > > This sounds somewhat similar to my suggestion in reply to Rainer's > email. > > Best -- Eric > > > > > -- > > Darlan Cavalcante > > > > > > At Fri, 21 Oct 2011 22:24:25 +0200, > > Christian Moe wrote: > >> > >> Hi, > >> > >> Yes, that works nicely, and should solve Rainer's problem. > >> I haven't been able to think of anything else that can't be handled by > >> properties. > >> > >> And I do think it's a good idea to winnow down the syntax a bit, even > >> if things break. I just like to grumble. > >> :-) > >> > >> Yours, > >> Christian > >> > >> On 10/21/11 7:37 PM, Eric Schulte wrote: > >> > Nice idea. This same issue with "var" arose when we first started > >> > allowing header arguments to be specified inside subtree properties. > >> > I've just implemented your suggestion so the following are now possible. > >> > > >> > #+PROPERTY: var foo=1, bar=2 > >> > #+PROPERTY: cache yes > >> > > >> > #+begin_src emacs-lisp > >> >(+ foo bar) > >> > #+end_src > >> > > >> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: > >> > : 3 > >> > > >> > and > >> > > >> > #+begin_src emacs-lisp :var foo="this", bar="that" > >> >(concat foo " " bar) > >> > #+end_src > >> > > >> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: > >> > : this that > >> > > >> > Thanks for the suggestion and I hope the above is a sufficient > >> > replacement for the now-missing #+BABEL: syntax. > >> > > >> > Cheers -- Eric > >> > >> > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/
Re: [O] Monthly Agenda View Start Date
On 24/10/11 07:51, Carsten Dominik wrote: Hi Ian, actually, there was a thread about this yesterday: thread.gmane.org/gmane.emacs.orgmode/48290/focus=48290 On Oct 24, 2011, at 8:34 AM, Ian Barton wrote: I have just started using the month view in Agenda. However, it displays the whole of the current month, starting from the first. What I really want is to display a month's view from today. I relize that I can do this with a custom Agenda command, but is there aready some variable I can set that allows me to do this? Thanks Carsten, that's exactly waht I needed. Ian.
Re: [O] Source blocks for tiny snippets
Nick Dokos writes: > It is documented in sec. 15.2, "Easy Templates", of > the org manual (along with how to add your own): > > (info "(org) Easy Templates") Thanks, I think I should take the dynamics of org-mode more into account - my not so old hard-copy of the manual is already out of date, apparently, it lacks that section. cheers -- Thorsten
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hello, Christian Moe writes: > But you're right, property inheritance is not on by default and > I forgot to mention that this time around. (I think I did mention it > in the previous long message where I presented the idea.) AFAIK, Babel has always searched its properties with inheritance on, independently on user configuration. Thus, it doesn't matter much in that case. Regard, -- Nicolas Goaziou
Re: [O] OPatches for org-generic-export
On 10/24/11 Oct 24 -9:44 AM, Wes Hardaker wrote: >> On Fri, 21 Oct 2011 19:23:04 +0200, Bastien said: > >>> Glad to see someone tinkering with it! yay! > > B> Could you test Robert's patches against latest Org and report > B> any problem? As the author of the generic exporter, you might > B> spot problems more easily... > > I think they looked fine without intense study, and I trust him to fix > bugs that come his way :-) > > Anyway, I really like the idea of an exporter test regression suite. > Now we just need to make that happen! The only challenge I see is the matcher. That is, I can create a test document, based on Jambunathan's, but I don't know the best way to write the tests. I suppose some form of regular expression is The Right Thing. There must be a better solution, though --- I figure someone must have a good way to match text files against expectations. I just don't know what that way is. cheers, r
Re: [O] notify, when something to do
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.
Re: [O] org-contacts or bbdb?
> On Sun, 23 Oct 2011 11:36:21 +0200, pmli...@free.fr (Peter Münster) said: >> go mess with the database easily. EG, with BBDB if one area gets a new >> area code you can't go quickly search/replace for all records replacing >> 111 with 222. With org-contacts it's a simple search/replace edit. PM> But you can open the bbdb-file and do the replacement there, can't PM> you? As a database, elisp dumps don't seem safe to edit. Yes you can, but the likely hood of running into other conflicts are problematic (IE, matching just the number 111 in just the area-code field when there is no easy near-by matching string to anchor a regexp against). -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/
Re: [O] OPatches for org-generic-export
> On Fri, 21 Oct 2011 19:23:04 +0200, Bastien said: >> Glad to see someone tinkering with it! yay! B> Could you test Robert's patches against latest Org and report B> any problem? As the author of the generic exporter, you might B> spot problems more easily... I think they looked fine without intense study, and I trust him to fix bugs that come his way :-) Anyway, I really like the idea of an exporter test regression suite. Now we just need to make that happen! -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/
Re: [O] [RFC] Standardized code block keywords
Does org have TAB completion in "call lines" for names of blocks that can be called? Using "srcname" for blocks of code could make things easier but if this is not the case then I "name" is just fine. -- Darlan At Mon, 24 Oct 2011 08:37:13 +0100, Eric S Fraga wrote: > > Daniel Bausch writes: > > > Hi, > > > >> 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. That a source block contains source is also > > obvious and is already noted by the use of #+begin_src, so why duplicate > > the > > "src"-part? > > > > Daniel > > I don't know if I've left it too late to vote on this but... > > I would go for "name" for [1] and [3] and "call" for [2]. > > I can, however, see the need for distinguishing between data tables and > results so could be convinced that "data" and "results" should be used > for [3]. In any case, I do know that I dislike srcname and tblname... > > -- > : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 > : using Org-mode version 7.7 (release_7.7.452.g767f5) >
Re: [O] Source blocks for tiny snippets
Thorsten wrote: > ... > There is, e.g., the shortcut > > ,--- > | `--- > > to insert a code-block, but its somehow underdocumented - I don't > remember, where I read about it, and don't find it in the manual > anymore. > It is documented in sec. 15.2, "Easy Templates", of the org manual (along with how to add your own): (info "(org) Easy Templates") Nick
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/24/11 2:11 PM, Sebastien Vauban wrote: (...) But I just have a comment on your second advantage, something that can render your example inefficient: inheritance is not on by default, and you need to enable if for *specific properties*. You can set `org-use-property-inheritance' to t, to make all properties inheritable, or you can set it to a list to enable specific properties. I suppose you meant that the former would be a bad idea. (And it could be, depending on your working habits, file size, outline nesting depth and the speed of your machine.) But you're right, property inheritance is not on by default and I forgot to mention that this time around. (I think I did mention it in the previous long message where I presented the idea.) Make it on by default would be a very bad idea -- just think at examples of the mails sent through Org-mime: what about setting a Cc or To somewhere and inheriting that in all the file/subtree/etc. May be scary or inefficient performance-wise? Anyway, setting inheritance of properties to on, means you should declare the behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you say that "var: x, y, z" does that too (then you've two things in one shot -- why not?). Yes, if my suggestion becomes reality, this could be a useful refinement. Yours, Christian
Re: [O] FYI: Org mode testing framework, Emacs 23 and 22
Hi Eric, Eric Schulte wrote: > "Sebastien Vauban" writes: >> Bastien wrote: >>> Jason, depending on our server resources, would that be feasible >>> to run regular (cron'ed) tests? What is the best frequency? >> >> Wouldn't the best frequency be: at every commit? >> >> That's not for the minute (maybe even less) it takes to run the 102 tests, >> I guess... > > At 8 seconds (on my machine) it shouldn't put too much load on the server to > run after every commit, we would just want to be sure that multiple > instances of the test suite are not run at once. A check to only run the > suite if it is not currently running shouldn't be difficult to run. 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? Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi all, Christian Moe wrote: >> This all sounds very interesting, but I have problems understanding >> the advantages - possibly because I only had one coffee this morning. > > I think some of the advantages should be clear. > > A second advantage: > --- > > It would allow a great deal of flexibility in passing variables > according to position in the outline hierarchy. > > #+BEGIN_EXAMPLE >* Some default settings > :PROPERTIES: > :x: 1 > :y: 2 > :z: -3 > :var: x, y, z > :END: > >** For all cases where y=5 > :PROPERTIES: > :y: 5 > :END: > >*** A case where x=1, y=5, z=-3 > >#+begin_src R > (...) >#+end_src > >*** A case where x=1, y=5, z=8: no need to specify y again > >#+begin_src R :var z=8 > (...) >#+end_src > >(z could alternatively have been specified as a property, same as y > above) > #+END_EXAMPLE > > This modular re-use of values from higher up in the outline, on any > number of levels, should more than compensate for the loss of > buffer-wide assignments with the #+BABEL header. > > With a single :var: property for passing arguments, on the other hand, > this is not possible. You have to re-assign values to all three > variables on each level. (Note: Eric's idea for accumulative > properties, on the other hand, /would/ allow you to do this with a > single :var: property.) I think discussing all of this is beneficial and can lead to very interesting solutions. But I just have a comment on your second advantage, something that can render your example inefficient: inheritance is not on by default, and you need to enable if for *specific properties*. Make it on by default would be a very bad idea -- just think at examples of the mails sent through Org-mime: what about setting a Cc or To somewhere and inheriting that in all the file/subtree/etc. May be scary or inefficient performance-wise? Anyway, setting inheritance of properties to on, means you should declare the behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you say that "var: x, y, z" does that too (then you've two things in one shot -- why not?). Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
This all sounds very interesting, but I have problems understanding the advantages - possibly because I only had one coffee this morning. It may not be feasible and the disadvantages may outnumber the advantages; we'll see. But having several coffees under my belt already, I'll argue my corner. :-) To recapitulate, I'm proposing that the values of (declared) variables for code blocks could be assigned from properties with the same names, so that: :PROPERTIES: :var: x=1, y=2, z=-3 :END: could also, and interchangeably, be written: :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: Here setting the `var' property with variable names, but without assignments, would declare that the variables are to be passed to the src block, and prompt Babel to look for the values in properties with the same names. I think some of the advantages should be clear. First: -- It would easily let code blocks collect data from Org entry properties, without having to use lisp expressions or first collecting the properties in a dynamic block and then referencing the d.b. This would be nice particularly when your data is already in outline/property form. A second advantage: --- It would allow a great deal of flexibility in passing variables according to position in the outline hierarchy. #+BEGIN_EXAMPLE * Some default settings :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: ** For all cases where y=5 :PROPERTIES: :y: 5 :END: *** A case where x=1, y=5, z=-3 #+begin_src R (...) #+end_src *** A case where x=1, y=5, z=8: no need to specify y again #+begin_src R :var z=8 (...) #+end_src (z could alternatively have been specified as a property, same as y above) #+END_EXAMPLE This modular re-use of values from higher up in the outline, on any number of levels, should more than compensate for the loss of buffer-wide assignments with the #+BABEL header. With a single :var: property for passing arguments, on the other hand, this is not possible. You have to re-assign values to all three variables on each level. (Note: Eric's idea for accumulative properties, on the other hand, /would/ allow you to do this with a single :var: property.) #+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) #+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz" I think this syntax opens the door for dangerous typos - If you type e.g: #+PROPERTY: vat x=10 what would this be? it should have been #+PROPERTY: var x=10 but now? Now there would be a :vat: property with the value "x=10". It will not be passed to any code block because (as I imagine the scheme) any variables to be passed to a code block still need to be /declared/ with a :var: property or :var header argument, so it will not conflict with any `vat' variable you might have defined in the code. Instead, you will notice the typo when your code block results in an error message that x is missing, same as now. The result of misspelling var under my scheme would be the same as misspelling it now. One could allow this syntax in the case that the variable has been defined before, by using the var syntax: To simplify your example, you think this is permissible: #+PROPERTY: var x, y, z #+PROPERTY: x 1 #+PROPERTY: y (1+ 1) #+PROPERTY: z (- 0 3) but this is not: #+PROPERTY: x 1 #+PROPERTY: y (1+ 1) #+PROPERTY: z (- 0 3) #+PROPERTY: var x, y, z As I imagine the scheme, it wouldn't matter and the two are interchangeable. The `#+PROPERTY: y (1+ 1)' assignment, in and of itself, would only create a property :y: with the string value "(1+ 1)". When Babel began to execute a code block, it would first look up the value of the property :var: at point to see what variables to pass, and the order of the PROPERTY headers is not important. It would then look for the values of the properties :x:, :y: and :z: at point, and only then, knowing that these are variables for a code block, would it evaluate any lisp expressions in these values. A third advantage: -- It would provide one way to solve your problem -- very long assignment expressions that are difficult to group on a line. It is not necessarily the best way to solve that specific problem, compared with the various options Eric came up with, such as #+PROPERTY+:. But this would not make #+PROPERTY+: redundant, but rather enhance it. Possibly; my solution only applies to the :var passed to a code block; there may be other property assignments that it would be good to be able to split over several lines. Also, I can certainly see the attraction of the analogous #+TBLFM+: -- though I'm fine with the existing `C-c '' solution for that, an
Re: [O] No updates on git server?
On Fri, Oct 21, 2011 at 5:39 PM, Bastien wrote: > Rainer M Krug writes: > > > [...] or has org reached a stable state? > > Is it April fools' day already? > > :) > I had the same idea, when no updates arrived for three days > > -- > Bastien > -- 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] Links to C/C++ source code lines
Bastien altern.org> writes: > > Looks nice, thanks. Just wondering: are you aware of the "A.3 Adding > hyperlink types" section in the manual? You core uses advice instead > of the `org-add-link-type' function -- is that on purpose? > No, I missed that paragraph. That would be a cleaner solution- I'll take a look at it. Thank for the hint! regards, Rafal
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 9:07 PM, Christian Moe wrote: > Hi, > > > Eric Schulte wrote: > >> >> > 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 >> > (...) > > >> 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: var MAINVERSION=0, >> > > #+PROPERTY+: SVNVERSION=(vc-working-**revision (buffer-file-name)), > (...) > > These are all interesting ideas, as was Darlan's alternative suggestion to > Eric's suggestion (1), namely to use a special inherit argument. > > I'd like to toss out a different idea, which I think is brilliant, but > which may go down in flames once we've had a time to think it through. (And > sorry if it's been proposed before; I came to Org just as Org-Babel was > being stabilized.) > > In short, let Babel assign to any declared variables of a src block the > values of any properties at point with the same name. In other words: > > - The :var header argument / :var: property could declare variables without > assigning values, that is, you could have > `:var foo=1, bar, baz=3' to tell Babel that `bar' is a variable too. > > - When a variable is declared, but no value assigned, Babel would look for > a property (e.g. `:bar: 2') at point with the same name as the variable. > > - If property inheritance is turned on, this means a variable can be > specified at any level of the outline. > > - If no further changes were made (such as the property accumulation Eric > suggested), it would still be possible to /declare/ variables only at /one/ > level of the outline besides in the code block and calls, since declarations > all belong to the same `:var:' property. However, this approach would mean > that declarations could be kept short and there would be a great deal of > modularity in what values would be assigned. This all sounds very interesting, but I have problems understanding the advantages - possibly because I only had one coffee this morning. In addition see further down: SNIP > On 10/22/11 5:52 PM, Eric Schulte wrote: > >> >>> #+BABEL: :var MAINVERSION=0 >>> #+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) >>> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.**tar.gz" >>> >>> > Have a buffer-level property for all the long lines (sorry if my email > client wraps these lines): > > #+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) > #+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz" > > I think this syntax opens the door for dangerous typos - If you type e.g: #+PROPERTY: vat x=10 what would this be? it should have been #+PROPERTY: var x=10 but now? One could allow this syntax in the case that the variable has been defined before, by using the var syntax: so #+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PACKAGE #+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) #+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz" should be OK, as SVNVERSION is already defined, but #+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) #+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz" #+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PACKAGE not, as the variables are only defined later. But this would not make #+PROPERTY+: redundant, but rather enhance it. Cheers, Rainer Cheers, Rainer SNIP > Yours, > Christian > -- 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] Source blocks for tiny snippets
Hi Eric, Eric Schulte writes: > That combined with a helper for specifying > code blocks (I use yasnippets for this) should serve. I would like to suggest adding the keybindings and shortcuts for specifying code blocks to chapter 14.11 "Key bindings and useful functions" in the manual. I'm still looking for a comfortabel way to specify a code-block without typing much. A summary of keybindings, shortcuts and completion methods available for this task in chapter 14 would be helpfull, even if there is some duplication of information given in other chapters. There is, e.g., the shortcut ,--- |
Re: [O] Source blocks for tiny snippets
Hi Eric,
On Sat, Oct 22, 2011 at 18:08, Eric Schulte wrote:
> suvayu ali writes:
>
>> Hi everyone,
>>
>> I was wondering what people do when they need to put a few (1 or 2)
>> lines of code snippets in org files? I like the syntax highlighting one
>> gets in an org buffer and in HTML export with code blocks. Is there some
>> work around other than have code blocks for every line I want to
>> include?
>>
>> As an example consider this paragraph:
>>
>> Edit job options for number of events and other configurations
>> : $ $EDITOR $GAUSSOPTS/.py
>> The number of events in a job can be customised with the option
>> : LHCbApp().EvtMax = nEvts
>> To run the generator only, set the property below.
>> : Gauss().Phases = ["Generator"]
>> To turn on full monitoring and dump an ntuple to a root file, include
>> the opts files as below. It can be customised further to suit the needs.
>> : importOptions('$GAUSSOPTS/.opts')
>>
>> In the above example you have a mix of bash and python snippets.
>>
>
> Currently there is no more concise way to specify code blocks other than
> the normal code block format. Although it doesn't currently exist maybe
> an option could be added to hide the #+BEGIN/END_SRC lines so that they
> don't appear in the buffer. That combined with a helper for specifying
> code blocks (I use yasnippets for this) should serve.
>
Thanks for the confirmation. I can live with example lines for now. :)
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 5:52 PM, Eric Schulte wrote:
> >
> > Just to add to it: at the moment I have e.g:
> >
> > #+BABEL: :var MAINVERSION=0
> > #+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)
> > #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
> >
> > which would look horrible in one line and a nightmare to edit.
> >
> > Any suggestions how this cold be changed?
> >
>
> Hmm, I don't see any easy solution for the above. I'm sorry to have
> removed this functionality.
>
> 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.
>
Should work, but will add an additional level of complexity which I think is
avoidable.
>
> 2. Adding a "#+PROPERTY:" line authoring helper similar to the table
> formula helper making it more natural to edit such long property
> lines.
>
I think this might be to complicated
>
> 3. It may be possible to add syntax for extending #+PROPERTY:
> specifications across multiple lines, something like
>
> #+PROPERTY: var MAINVERSION=0,
> #+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),
> #+PROPERTY+: DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
>
> FWIW I would like to have a similar extender for #+TBLFM: lines.
> Actually this choice may be my preferred solution.
>
I like that suggestion - This would add an option, if inheritance for
subtrees is incorporated for #+PROPERTY to unset all variables - something I
was looking for some time ago.
So I really like that solution: logical, clear, does not break anything, and
easy to read - I would say go for it.
>
> What do you think?
>
> >
> > In addition: I would like to have a warning if #+BABEL is present in the
> org
> > file, so that one remembers that it has to be changed.
> >
>
> #+begin_src emacs-lisp
> (add-hook 'org-mode-hook
>(lambda ()
> (save-excursion
>(goto-char (point-min))
>(when (re-search-forward (org-make-options-regexp
> '("BABEL")))
> (message "This file contains a \"#+BABEL:\" line.")
> #+end_src
>
Could this be included in the next few versions of org, as I can imnagine
that especially infrequent org-babel users will be confused. Also: in a
year, when I open an old org-file and it des not work, this would warn me
about the necessary modifications.
Cheers,
Rainer
>
> Cheers -- Eric
>
> --
> 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
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] [RFC] Standardized code block keywords
Daniel Bausch writes: > Hi, > >> 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. That a source block contains source is also > obvious and is already noted by the use of #+begin_src, so why duplicate the > "src"-part? > > Daniel I don't know if I've left it too late to vote on this but... I would go for "name" for [1] and [3] and "call" for [2]. I can, however, see the need for distinguishing between data tables and results so could be convinced that "data" and "results" should be used for [3]. In any case, I do know that I dislike srcname and tblname... -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.7 (release_7.7.452.g767f5)
Re: [O] Recurring events with exceptions
Skip Collins writes: [...] > Lemerre's approach only syncs with the Outlook client, not the > Exchange server. He suggests using RFC-2446 (iCalendar) as a basis for > a more general solution. I think that trying to establish a smoothly > syncing connection between org and exchange by using iCalendar is a > recipe for frustration. This is mostly because Exchange's > implementation of the standard is lacking. > > It might be more fruitful to pursue an org interface to Exchange Web > Services, which is favored and privileged by microsoft. A hypothetical > org-ews.el would pass xml messages that look something like: > > > http://www.w3.org/2001/XMLSchema-instance"; [...] > For individual one way transfers, this would relatively straightforward, assuming that the relevant xml schema are well defined. As a proof of concept, I use separate one way transfers to sync my org files with google's calendar. Messy and ad hoc but it works; search the mailing list for a description of how I did this -- I'm offline at the moment so cannot search myself. Alternatively, look at [Worg]/org-tutorials/org-google-sync.html for a tutorial written by Arun Persaud that might give you an idea of how this can be done. HTH, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.7 (release_7.7.452.g767f5)
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 9:58 AM, Christian Moe wrote: > On 10/21/11 8:40 PM, Rainer M Krug wrote: > >> >> >> Just to add to it: at the moment I have e.g: >> >> #+BABEL: :var MAINVERSION=0 >> #+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) >> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.**tar.gz" >> >> which would look horrible in one line and a nightmare to edit. >> >> Any suggestions how this cold be changed? >> > > Wow. I guess I was wrong to imagine your problem was solved. > > If your code blocks share the same language, and it supports sessions, I'd > bite the bullet and transform them into #+HEADERS lines for the first src > block, then reuse them through a session. Does that make sense? > > If your variables are going to be used by different src blocks in different > languages, I don't have any elegant solution. > Yep - different languages: R and sh > > Yours, > Christian > > > > > > > > > > > > -- 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] notify, when something to do
Bastien, Bastien wrote: >> - How to distinguish between SCHEDULED and DEADLINE? I'll >> investigate... > > I introduced the ability to use > > (org-agenda-to-appt nil t :scheduled) > > if you just want to get scheduled appointments. This might > speeds things and make them more flexible. I have the impression we use SCHEDULED here with a wrong semantics. What about the idea (launched by Carsten) of introducing another keyword like APPT or EVENT [1] for such events to be warned of? Best regards, Seb Footnotes: [1] http://www.mail-archive.com/emacs-orgmode@gnu.org/msg45063.html -- Sebastien Vauban
Re: [O] Can't use char ">" in TODO state
Hi Nicolas, Nicolas Goaziou wrote: > Bastien writes: >> Michael Brand writes: >> >>> It works with this patch >>> http://patchwork.newartisans.com/patch/964 >>> from Nicolas which I am still using to test it. > >> If so, then Nicolas please apply it. It really simplifies >> the way headlines are matched in many places in the code. > > I've applied it. This works as expected from my point of view. Thanks a lot... Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Standardized code block keywords
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. Best regards, Seb -- Sebastien Vauban
