Bug: ob-python mangles multiline :var values [9.3.6 (release_9.3.6-397-ga089600)]
Recipe: --- emacs -Q M-x load-library RET ob-python RET M-x org-mode RET #+begin_src python :var text="a\nb\nc" return text #+end_src #+RESULTS: : a : b : c Commentary: --- ob-python seems to prepend a TAB character to every line except for the first one. Emacs : GNU Emacs 28.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.24.14, cairo version 1.17.3) of 2020-03-11 Package: Org mode version 9.3.6 (release_9.3.6-397-ga08960 @ /home/stepnem/.emacs.d/lib/org/lisp/)
[PATCH] org-eldoc: Use eldoc-documentation-functions when available
This reflects recent changes in GNU Emacs master branch: 2020-02-25T17:53:04-05:00!mvote...@udel.edu c0fcbd2c11 (Expose ElDoc functions in a hook (Bug#28257)) * lisp/org-eldoc.el (org-eldoc-load): Use 'eldoc-documentation-functions' when available. --- contrib/lisp/org-eldoc.el | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/contrib/lisp/org-eldoc.el b/contrib/lisp/org-eldoc.el index b4fc0c866..72b10a1fb 100644 --- a/contrib/lisp/org-eldoc.el +++ b/contrib/lisp/org-eldoc.el @@ -161,7 +161,11 @@ (defun org-eldoc-documentation-function () (defun org-eldoc-load () "Set up org-eldoc documentation function." (interactive) - (setq-local eldoc-documentation-function #'org-eldoc-documentation-function)) + (if (boundp 'eldoc-documentation-functions) + (add-hook 'eldoc-documentation-functions + #'org-eldoc-documentation-function nil t) +(setq-local eldoc-documentation-function + #'org-eldoc-documentation-function))) ;;;###autoload (add-hook 'org-mode-hook #'org-eldoc-load) -- 2.25.1
Re: [O] Org syntax inside verbatim/literal blocks
On Sat, 17 Aug 2019 15:24:56 +0200
Nicolas Goaziou wrote:
> I thought the idea was to move the information outside of the footnote.
> I applied a different patch, in master. Let me know if it is enough.
I agree that is even better; I guess I was aiming at minimal changes,
plus the footnote indexing thing seemed an interesting challenge...
> Side note: you cannot use CINDEX keyword in a footnote definition
> because Texinfo inlines them, which is not compatible with @cindex
> commands.
Hm, but the version in my patch does seem to work correctly, i.e. it is
exported as (snipped)
You need to exit by pressing @kbd{C-c '} again@footnote{@cindex escape
character
@cindex comma
Upon exit, lines starting with @samp{*}, @samp{,*}, @samp{#+} and @samp{,#+}
get
... which seems to produce a valid info file (looks the same as before
and the index entries work). Is it just a corner case, not a feature?
(I'm merely being curious at this point, I agree your version is better.)
Thank you.
--
Štěpán
Re: [O] Org syntax inside verbatim/literal blocks
> Certainly. Would you want to provide a patch to the manual?
Yes, thank you, patch attached (on top of current maint branch).
I don't know how robust the footnote indexing is, e.g. putting #+cindex
above instead of below [fn] lead to errors during 'make info'; but the
version attached does work (for the texinfo export at least).
--
Štěpán
>From bcd5049620e938c8687f239c10248db3805de721 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?=
Date: Thu, 15 Aug 2019 11:57:17 +0200
Subject: [PATCH] org-manual: Index and link to information on literal block
comma escape
* doc/org-manual.org (Escape Character): Mention comma and link to the "Literal
Examples" section.
(Footnotes): Index explanation of comma escape inside literal blocks.
---
doc/org-manual.org | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 1418abb50..06d5eb262 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18292,8 +18292,9 @@ init file[fn:146].
You may sometimes want to write text that looks like Org syntax, but
should really read as plain text. Org may use a specific escape
character in some situations, e.g., a backslash in macros (see [[*Macro
-Replacement]]). In the general case, however, we suggest to use the
-zero width space. You can get it with one of the following:
+Replacement]]) or a comma in source code and example blocks (see
+[[*Literal Examples]]). In the general case, however, we suggest to use
+the zero width space. You can get it with one of the following:
: C-x 8 zero width space
: C-x 8 200B
@@ -21354,7 +21355,10 @@ information on evaluating code blocks.
while using line numbers for the links, which might be useful to
explain those in an Org mode example code.
-[fn:117] Upon exit, lines starting with =*=, =,*=, =#+= and =,#+= get
+[fn:117]
+#+cindex: escape character
+#+cindex: comma
+Upon exit, lines starting with =*=, =,*=, =#+= and =,#+= get
a comma prepended, to keep them from being interpreted by Org as
outline nodes or special syntax. These commas are stripped when
editing with {{{kbd(C-c ')}}}, and also before export.
--
2.22.0
Re: [O] Org syntax inside verbatim/literal blocks
On Fri, 09 Aug 2019 22:39:44 +0200
Nicolas Goaziou wrote:
>> But all I could find in the manual regarding "verbatim", "escaping" etc.
>> are sections 12.2 and 16.3, neither of which mentions comma.
>
> See "Literal Examples" section, fourth footnote.
Thanks.
I think it would be much more helpful if, instead of a footnote to one
related special case (`org-edit-special'), this information was indexed
("escape character" and "comma" come to mind) and also mentioned in or
linked to from section 16.3 (Escape Character).
What do you think?
--
Štěpán
[O] Org syntax inside verbatim/literal blocks
I notice that even inside example blocks, some strings are still parsed as Org syntax, e.g. the asterisk becomes a bogus heading: #+begin_example * _ \| @ \ |_/ /\ /\ #+end_example When I enclose the text in a region and use `org-insert-structure-template' to surround it with begin and end lines, a comma is prepended to the asterisk automatically (doc string of `org-escape-code-in-region' uses the word "append", which is usually used in the sense of "add to the end", though). But all I could find in the manual regarding "verbatim", "escaping" etc. are sections 12.2 and 16.3, neither of which mentions comma. I'd prefer if there were some kind of a _real_ verbatim block without need for escaping anything, but failing that, could this matter be clarified in the documentation? Thanks, Štěpán
Re: [O] Bug: Feature request: make org-link emacs wide mode [9.2.5 (9.2.5-elpa @ /home/data1/protected/.emacs.d/elpa/org-20190801/)]
> I would like to request feature so that Org Links can be turned on > Emacs wide as org-link-mode. Then links could work in various buffers, > and this could make hyperlinking possible from any kinds of files. For reference: https://github.com/seanohalpin/org-link-minor-mode https://github.com/tarsius/orglink -- Štěpán
[O] [babel-bug] Text properties silently stripped from code block evaluation results
`org-babel-insert-result' unconditionally strips any text properties from the evaluation result. One problem is that this isn't documented. Another problem is that this behaviour might not be desirable (I can't imagine why one _would_ want to have the properties stripped, on the contrary -- I need them preserved in at least one of my use cases). Please document the behaviour and either abstain from the strip-tease altogether or provide a way to switch it off. -- Štěpán
Re: [O] Elisp programming style
On Thu, 27 Oct 2011 20:03:22 +0200 Thorsten wrote: > Hi List, > doing some Elisp programming (in an orgmode context) recently, the > following question with regards to the 'accepted programming style' for > Elisp concerned me: > > How independent and self-sustained should helper functions be? > > I found some redundancy in elisp code, e.g. several (main and helper) > functions that do exactly the same thing to extract the same specific > args out of an argument list. My first reaction was, to factor out this > extraction into the main function, and then call the helper functions > from inside a (let ...) environment where the extracted args are stored > in a local variable. > > But then I recognised, that the helper functions cannot be called > independently anymore, but only make sense when called from this one > main function with its local bindings. > > Is there a kind of convention in a case like this? Like: "Make every function, > even a helper function, independent, and don't care about redundancy"? > Just being curious Too bad you didn't give any concrete examples. In general, if the helper function is only used in a single place and isn't likely to be more generally useful, there might be no reason for it to be a standalone function at all (other than modular programming, which is always a good idea IMO). OTOH, if the helper function _is_ standalone and used in multiple places, then there is no "redundancy", so I'm really not sure what you mean. If I understand you correctly, you find multiple pairs of main and helper functions, where the helper does very similar things. In that case the right thing would seem to be to abstract all the helpers into a single helper and use that in all the main functions. [To clarify, this all is just an opinion of an interested Emacs and Org user who often pulls his hair when trying to make use of/fix bugs in existing code and bumping into lacks in modular design. The maintainers will perhaps provide more authoritative guidelines.] -- Štěpán
Re: [O] [babel] What is `, (backquote comma)?
On Wed, 21 Sep 2011 21:05:12 +0200 Thorsten wrote: > thanks Nick and Stepan, > > "evaluate the form after "," and quote the result" > > that made me understand what its all about. > I just read the backquote section Elisp manual, it does not cover these > strange combiniations of barely distinguable characters, but I may haved > missed it - its a thick book. You haven't missed anything. My point was that "the pieces are all there" -- as Nick pointed out by the rewriting, 'foo is just a convenient read syntax for (quote foo), so there's nothing special or new about `',foo, it's still manipulating a list structure in a way the manual describes. I'm sure you can find more resources on the net, as the same notation is used in other Lisps, in particular Common Lisp and Scheme. Two examples I know of: http://www.lispworks.com/documentation/HyperSpec/Body/02_df.htm http://bc.tech.coop/blog/041205.html (And by the way, if you really find ' and ` "barely distinguishable", perhaps you might consider using another font? It's an important distinction to make, as you've now found. ;-)) -- Štěpán
Re: [O] [babel] What is `, (backquote comma)?
On Wed, 21 Sep 2011 19:37:42 +0200 Thorsten wrote: > in org-babel-expand-body:scheme (and > e.g. org-babel-expand-body:emacs-lisp) I encounter something like this: > > (lambda (var) (format "%S" (print `(,(car var) ',(cdr var) > > While this part > `(,(car var) ...) > is explained in the manual (backquote and unquote), this part > `(... ',(cdr var)) > is a bit mysterious to me, and I do not find information about > backquote( ... backquote comma ()) > in the manuals or the web. > > Is that Emacs Lisp? What does that mean? Note it's not "`,", which would indeed be a no-op, but "',", which here means "evaluate the form after "," and quote the result", IOW, the "'" is just left there (for the same reason you also get to see the even more funny-looking "`'," and other variations sometimes). Really nothing new if you've read the backquote section of the Elisp manual. -- Štěpán
Re: [O] [PATCH 0/5] loop over headlines in active region
On Fri, 09 Sep 2011 17:10:42 +0200 David Maus wrote: > At Fri, 09 Sep 2011 12:26:31 +0200, > Štěpán Němec wrote: >> >> Still, I'd rather we stuck to the point and expressed ourselves in a way >> that doesn't imply the other side is either an idiot ... > > Your message simply repeated my conclusion: Yes, the problem of > referencing a free variable in the macro expansion does not apply in > this case. Yes, I should base decisions on valid arguments (Who > shouldn't?). Yes, the fact that I refrained from implementing it as a > macro indicates that I wanted to implement it as a macro in the first > place. > > Repeating and stating the very, very obvious is one way to call > someone an idiot. It's not. (One way to call someone an idiot is saying "You're an idiot". If you somehow understood any of my emails as implying you're an idiot, then I'm sorry. It was definitely not intended.) The reason I asked (I didn't actually repeat anything, and it's all apparently still far from obvious, at least to me) is that I'm confused: You say "I didn't implement is as a macro, because A". Now we both agree that A is an invalid argument. Given that you now also confirmed you did want to implement it as a macro in the first place, I would expect that either you do implement it as a macro, or provide a valid argument for not doing so. Maybe I really am too dense, but the hitchhiker quotation didn't help. -- Štěpán
Re: [O] [PATCH 0/5] loop over headlines in active region
On Fri, Sep 09, 2011 at 12:41:45PM +0200, Bastien wrote: > Guys, let's keep using a civil tone in discussions. I think you're confusing "civil tone" with "political correctness" (which, in a lot of instances, can be translated as "hypocrisy"). I don't think every sentence containing the word "idiot" is uncivil, if that's what tripped you up. In any case, I really appreciate David's contributions focused on improving Org code quality. I even more appreciate that he sends his patches to the list so that anyone can review and comment on them. It's just that I believe it's more helpful to stick to the point being discussed and address questions raised instead of spamming the list with one's reading notes. -- Štěpán
Re: [O] [PATCH 0/5] loop over headlines in active region
On Fri, 09 Sep 2011 06:06:26 +0200 David Maus wrote: > At Wed, 07 Sep 2011 21:34:41 +0200, > Štěpán Němec wrote: >> So your "what stop me to implement a macro" argument is bogus, isn't it? >> I can't really comment on whether using a macro or not is the right >> thing here, but it seems to me you shouldn't base the decision on an >> invalid argument (IOW, from the fact that you even felt the need to >> explain why you didn't use a macro to begin with, it would appear to be >> the case that you would have preferred the macro way). > > "One of the things Ford Prefect had always found hardest to understand > about humans was their habit of continually stating and repeating the > very very obvious, as in /It's a nice day/, or /You're very tall/, or > /Oh dear you seem to have fallen down a thirty-foot well, are you all > right?/ At first Ford had formed a theory to account for this strange > behavior. If human beings don't keep exercising their lips, he > thought, their mouths probably seize up. > > After a few months' consideration and observation he abandoned this > theory in favor of a new one. If they don't keep on exercising their > lips, he thought, their brains start working. After a while he > abandoned this one as well as being obstructively cynical and decided > he quite liked human beings after all, but he always remained > desperately worried about the terrible number of things they didn't > know about." > > Douglas Adams, The Hitchiker's Guide to the Galaxy In your "enlightened" style, that would be “曰：‘四境之內不治則如之何？’王顧左右而言他。” 《孟子·梁惠王下》 Still, I'd rather we stuck to the point and expressed ourselves in a way that doesn't imply the other side is either an idiot or a telepathist (although I'd argue that in the currrent context, my quotation is much clearer than yours). -- Štěpán
Re: [O] [PATCH 0/5] loop over headlines in active region
On Sun, 28 Aug 2011 15:57:19 +0200 David Maus wrote: > At Thu, 25 Aug 2011 12:08:42 +0200, > Štěpán Němec wrote: >> >> On Thu, 25 Aug 2011 06:25:29 +0200 >> David Maus wrote: >> >> > As for the macro: What stop me to implement a macro for the generic >> > operation is that for now the macro would depend on the global >> > customization variable. That's not a problem per se but according to >> > my readings about macros (mostly in context of Common Lisp, but that >> > shouldn't matter) it should be considered bad style. >> >> Could you expand on this a bit? As far as I can tell, you obviously >> shouldn't depend on a customisation variable at macro expansion time, >> but I don't see how depending on it at run time is any different from a >> function doing the same. >> > > At expansion time the macro performs a transformation of the lisp at > the place where the macro is used. At runtime the code of the expanded > macro runs in the scope of the function where the macro was expanded > into. A macro that uses a variable inside the expanded code that is > not under its control (e.g. part of the argument list or gensym'd) is > prone to introduce a bug caused by expanding the macro in an > environment where this variable is not bound or used with a different > semantics. > > In this particular case this should not be a problem indeed because we > use a global dynamically scoped customization variable. Thus, > whereever we would use the macro we can be sure the variable in the > macro expansion is bound and carries the same meaning. So your "what stop me to implement a macro" argument is bogus, isn't it? I can't really comment on whether using a macro or not is the right thing here, but it seems to me you shouldn't base the decision on an invalid argument (IOW, from the fact that you even felt the need to explain why you didn't use a macro to begin with, it would appear to be the case that you would have preferred the macro way). -- Štěpán
Re: [O] [PATCH 0/5] loop over headlines in active region
On Thu, 25 Aug 2011 06:25:29 +0200 David Maus wrote: > As for the macro: What stop me to implement a macro for the generic > operation is that for now the macro would depend on the global > customization variable. That's not a problem per se but according to > my readings about macros (mostly in context of Common Lisp, but that > shouldn't matter) it should be considered bad style. Could you expand on this a bit? As far as I can tell, you obviously shouldn't depend on a customisation variable at macro expansion time, but I don't see how depending on it at run time is any different from a function doing the same. -- Štěpán
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
[As most people here apparently consider Jambunathan's communication style acceptable, there is little point for me to continue replying in this thread, but I really couldn't resist in this case, sorry.] On Wed, 24 Aug 2011 19:30:54 +0200 Allen S. Rout wrote: > Jambunathan is abrupt and speaks without much concern for the feelings of the > recipients of his messages. He has great concern for the exact meaning of his > words, and for being technically correct. This makes him an extremely > uncomfortable conversational partner, and an extremely rewarding > collaborator. I'm (sincerely) glad you have some positive experience to share, but you're really being much too generous with regard to this thread. Utterances like "I am willing to overlook the fact that he seriously pissed me off with unkind words and committed a greater faux paus by inviting Lennart Borgman in to merge discussions." or "When I criticized him he is labelling me insulting, patronizing and frustrated. Seriously to how low a level this person has to go." (and many others, as well as the general "everybody except me is an idiot" spirit permeating many of Jambunathan's e-mails) have nothing to do with "concern for the exact meaning" of anything. Such words are not even condescending. They're just insane and for me personally disqualify their originator from any possible collaboration until he comes to his senses again _precisely_ because I value not only basic civity, but also rationality and exactness. -- Štěpán
Re: [O] Not merging org-lparse, org-xhtml & org-odt to the core
On Wed, 24 Aug 2011 01:46:35 +0200 Jambunathan K. wrote: >> Hi Jambunathan, >> >>> I have made a decision not to merge org-lparse, org-xhtml & org-odt in >>> to Orgmode core. It is a very difficult decision for me to take >>> considering that I had put all my heart in to it. (Btw, this decision >>> has nothing to with me not having enough time at hand.) >> >> As all, I'm puzzled by this statement, and wonder what went wrong >> somehow. > > Without mincing words, Bastien has to learn how to respect and engage > with serious contributors. He should take time to look at the data > presented to him and put some serious effort before sending out an > email. I am willing to overlook the fact that he seriously pissed me off > with unkind words and committed a greater faux paus by inviting Lennart > Borgman in to merge discussions. I am sorry to say this - Lennart > Borgman did a half-baked work. > > I have been patient and tried my best to be as co-operative as > possible. He just manages to get me on my nerves somehow. He simply > didn't have the courtesy to reply to my mails when he simply disappeared > from the list for 3 months or so. I hate to such callous attitude who > claims to be a maintainer and wants to act like a maintainer. > >> What you did is a really important piece of the puzzle, as it finally >> let us cooperate more easily with people we can't convert as >> Org'ers. At least, they won't bother us to fit their software >> requirement: we can work in Org up till the very end, and then produce >> a final result in the expected (by others) format. >> >>> I leave it up to the community on what would be the best place to "host" >>> this software. >> >> For me, the answer to this was/is clear: Org-mode itself, hence the reason >> why I don't understand the above. > > I have definite ideas on how the merge should proceed. He should be > willing to concede to the fact that I have a far better understanding on > what the most effective method of merge is. > > Bastien has stepped in to big shoes and he has to measure up. So "frustrated" is a dirty word for you? How about "a conceited moron"? Bastien might be an incompetent maintainer or programmer (in any case, you seem to be the first to make such claims), but he's certainly more than willing to deal with it. You've shown more than once here that you're rather incompetent as a contributor and a person[1]. I find it quite surprising that people on this list, including Bastien, are even willing to reply to the dirt you're spitting up. [1] Another example of the Jambunathan style: http://thread.gmane.org/gmane.emacs.orgmode/42544/focus=42563 -- Štěpán
Re: [O] [PATCH 2/7] New macro: Evaluate FORM in ENVIRONMENT
On Tue, 02 Aug 2011 11:23:35 +0200 David Maus wrote: > * org-macs.el (org-eval-in-environment): New macro. Evaluate > FORM in ENVIRONMENT. > (org-with-uninterned): Move to top of file. > --- > lisp/org-macs.el | 23 ++- > 1 files changed, 18 insertions(+), 5 deletions(-) > > diff --git a/lisp/org-macs.el b/lisp/org-macs.el > index 53c60e5..7a0cc60 100644 > --- a/lisp/org-macs.el > +++ b/lisp/org-macs.el > @@ -47,6 +47,12 @@ > (declare-function org-add-props "org-compat" (string plist &rest props)) > (declare-function org-string-match-p "org-compat" (&rest args)) > > +(defmacro org-with-uninterned (symbols &rest body) > + `(let ,(mapcar (lambda (s) > +`(,s (make-symbol (symbol-name ',s symbols) > + ,@body)) > +(put 'org-with-uninterned 'lisp-indent-function 1) > + So in the previous commit you added this macro, in the next commit you move it to the top of the file? Why didn't you put it into the right place to begin with? [...] > +(defun org-make-parameter-alist (flat) > + "Return alist based on FLAT. > +FLAT is a list with alternating symbol names and values. The > +returned alist is a list of lists with the symbol name in car and > +the value in cdr." > + (when flat > +(cons (list (car flat) (cadr flat)) > + (org-make-parameter-alist (cddr flat) This new function is not mentioned anywhere in the commit message. -- Štěpán
Re: [O] [PATCH 0/8] Org mode macros, refactored
On Tue, 02 Aug 2011 11:23:33 +0200 David Maus wrote: > Note: The usage of make-symbol works but has one drawback: The new > uninterned symbols have the same name as the maybe interned symbols in > BODY. An oft-used workaround (also occuring in the Emacs core code) is to add some line-noise (e.g. --symbol--) to the created symbol names so they are at least visually distinguishable. -- Štěpán
Re: [O] Some remarks on org-contacts
"Sebastien Vauban" writes: > And the cherry on the cake would be: snarfing data from received email, asking > the user what to do when a new email address is detected for a known contact, > or a new name detected for a known email address... > > Having those definitely would make org-contacts more powerful than BBDB -- > though, I don't know what's planned in v3 of BBDB. Just for anti-mystification's sake: BBDB has had all of the features you mention for (tens of) years. Štěpán
Re: [O] pdf to powerpoint/openoffice ?
Mehul Sanghvi writes: > How does someone who does not have a git checkout of org-mode do this ? > > I get the following: > > prompt% cd ~/Env/emacs > > prompt% mkdir org-odt ; cd org-odt > > prompt% git remote add org-odt http://repo.or.cz/r/org-mode/org-jambu.git > fatal: Not a git repository (or any of the parent directories): .git You seem to want this instead: cd ~/Env/emacs git clone http://repo.or.cz/r/org-mode/org-jambu.git org-odt Štěpán
[Orgmode] Re: Adding a new text/org mime type
Julien Danjou writes: >> Please change it in the most sensible way. > > I've changed to text/x-org. Unless I'm missing something, you forgot to also replace your other additions in mm-decode.el and mm-uu.el. Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Adding a new text/org mime type
Julien Danjou writes:
> On Fri, Jan 21 2011, Štěpán Němec wrote:
>
>> I see you added a new text/org type to mailcap.el and other places.
>> Shouldn't that rather be text/x-org? Or is this text/org registered with
>> IANA?
>
> No idea, but C-c C-a with a .org file proposes text/org by default.
Right... that's because `mailcap-mime-extensions' contains
(".org" . "text/org")
...which doesn't necessarily mean it's correct. I have no idea myself,
so I'm cc-ing the Org list, perhaps somebody there can provide more
insight.
Štěpán
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [babel] Painless integration of source blocks with language
"Eric Schulte" writes: > Hi Seth, > > Thanks for the thoughtful comments. I especially like the method of > literate programming described in your second proposal. Over the last > months I have switched from working mainly in code blocks to working > mainly in pure source files due to issues along the lines of those > mentioned in your first proposal. BTW, why is there not an option that would enable all mode-specific key bindings inside source blocks? It could be implemented e.g. by putting the mode keymap into the `keymap' text property. Seems like a simple solution. Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Capture template and elisp expression
Carsten Dominik writes: > On Jan 7, 2011, at 4:00 PM, Štěpán Němec wrote: > >> Carsten Dominik writes: >> >>> On Jan 7, 2011, at 1:08 PM, Štěpán Němec wrote: >>>> Why aren't the %() expressions simply evaluated in the original buffer >>>> (if available)? That would solve these issues in a general way. It seems >>>> to me that there is no advantage to evaluating the expressions in the >>>> temporary capture buffer, but I'm not familiar with the code so I might >>>> be missing something. Is there a reason for that? >>> >>> The sexp can be used to insert stuff into the template, so I think it >>> is correct to evaluate it in the template buffer. >> >> I don't understand this argument. Of course the _result_ of the >> evaluation is inserted into the template, but why is it useful to >> evaluate the expression itself in the context of the template buffer? Is >> it likely that one would be interested in some information only >> available in the template buffer? To me it seems that the much more >> likely case is the one of Rainer -- i.e. the need to access variable >> bindings from the original buffer (buffer name, mode, other local >> variables etc.). > > > Such a function is allowed to do anything. It might search around > in the template, change things, whatever. So I don't think it > should be evaluated in a different buffer. OK, thank you for the explanation. One can always do (with-current-buffer (org-capture-get :original-buffer) ...) should the need arise. Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Capture template and elisp expression
Carsten Dominik writes: > On Jan 7, 2011, at 1:08 PM, Štěpán Němec wrote: >> Why aren't the %() expressions simply evaluated in the original buffer >> (if available)? That would solve these issues in a general way. It seems >> to me that there is no advantage to evaluating the expressions in the >> temporary capture buffer, but I'm not familiar with the code so I might >> be missing something. Is there a reason for that? > > The sexp can be used to insert stuff into the template, so I think it > is correct to evaluate it in the template buffer. I don't understand this argument. Of course the _result_ of the evaluation is inserted into the template, but why is it useful to evaluate the expression itself in the context of the template buffer? Is it likely that one would be interested in some information only available in the template buffer? To me it seems that the much more likely case is the one of Rainer -- i.e. the need to access variable bindings from the original buffer (buffer name, mode, other local variables etc.). Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Capture template and elisp expression
Carsten Dominik writes: > On Jan 6, 2011, at 11:26 PM, Nick Dokos wrote: > >> Rainer M Krug wrote: >> >>> >>> Hi >>> >>> I want to use a Capture Template to record changes to files under >>> version control. Everything works as expected, but I would like to >>> include the current revision in the template. >>> >>> Therefore I tried the following: >>> >>> * %T %? at %a by Rainer M Krug, email: rai...@krugs.de >>> %(vc-working-revision buffer-file-name) >>> >>> for the template, but I get an error: >>> >>> <2011-01-06 Thu 13:06> at >>> [[file:~/Documents/Projects/BiocontrolAndAlienDynamics/ >>> nonSpatialAcacia/trunc/R/nsa.org::*Finalise][Finalise]] >>> by Rainer M Krug, email: rai...@krugs.de %![Error: (wrong-type- >>> argument >>> stringp nil)] >>> >>> Any idea how I could get the revision of the org file from which the >>> Capture has been initiated (here >>> ~/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/ >>> trunc/R/nsa.org >>> )? >>> >> >> There are a few problems: the evaluation of the sexp happens in the >> capture buffer where buffer-file-name returns nil. Even if you could >> get the file name, vc-working-revision would return nil on a file that >> is not VC-registered and the template would barf. >> >> Those are easy problems to solve but there is another one that seems >> insurmountable (with current code): my original thought was to use the >> %a escape to pass the link to a lisp function, extract the file name >> from it[fn:1] and run vc-working-revision on it (with appropriate safeguards >> to catch non-VC files), something like this: >> >> "* %T %? at %a by Rainer M Krug, email: rai...@krugs.de%(rk- >> custom-function-to-get-vc-revision \"%a\")" >> >> However, this fails because at the time that %(sexp) constructs are >> expanded, simple %a etc. constructs have not been expanded yet, so what >> the function above gets is a literal "%a": the subtitution sequence is >> >>;; %[] Insert contents of a file. >> >>... >> >>;; %() embedded elisp >> >>... >> >>;; Simple %-escapes >> >> (see lisp/org-capture.el, lines 1181-1229 or so). >> >> Moreover, this sequence was different and was changed deliberately (see >> the thread http://thread.gmane.org/gmane.emacs.orgmode/27649), so if it >> is changed back, Sebastion Rose will not be happy :-) >> >> So it seems there is no way to pass values from the capture context to a >> lisp function in the capture template, but maybe I'm missing something. >> >> Thanks, >> Nick >> >> Footnotes: >> [fn:1] Is there an easier way to get the filename of the file I was >> visiting when I initiated the capture? If not, should there be? Perhaps >> a %f escape? > > Hi Nick, > > you can use > > (buffer-file-name (org-capture-get :original-buffer)) > > and we could certainly introduce a special escape for it if helpful. > > If it is easier, we can also put the filename itself into the property list, > and any other information we like. This should happen in the function > org-capture, > close to the location where the buffer is stored, so near this line: > > (org-capture-put :original-buffer orig-buf :annotation annotation >:initial initial) > > org-capture uses this property list precisely so that it is simple > to add any information required. > > Note that, after the template has been filled in, it is better > to access information in the property list with > > > (org-capture-get PROPERTY 'local) > > to avoid conflicts with other ongoing capture processes. > > Hope this helps. Why aren't the %() expressions simply evaluated in the original buffer (if available)? That would solve these issues in a general way. It seems to me that there is no advantage to evaluating the expressions in the temporary capture buffer, but I'm not familiar with the code so I might be missing something. Is there a reason for that? Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: should the mail list be splitted resp. sub-tagged ?
Bastien writes: > Hi Štěpán, > > Štěpán Němec writes: > >> FWIW, I do. Having [Org] (or anything, really) prepended to the subjects >> of _all_ mails coming from a list that is already uniquely identifiable >> (e.g. by its address) has no information value altogether (unlike >> [Babel], [PATCH] etc.) and only takes up the much precious Subject: >> header space. > > Not that reducing the label from [Orgmode] to [Org] already seem to be a > progress in the right direction :) > > Would you object having [Org] instead of [Orgmode]? Well, I wrote "anything", so, yeah ;-) But I actually usually read the list through Gmane, so I'm mostly unaffected (and Gnus can also strip the list identifier automatically). I still find any kind of such server-side mangling Evil (see also Robert Pluim's reply, most of which I could just sign myself), but from Nick Dokos' reply I see that for people putting all incoming mail into one single place and not able or willing to do anything more than that it can have its uses, so, each to their own I guess... Thank you for consideration, Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: should the mail list be splitted resp. sub-tagged ?
Bastien writes: > Hi Torsten, > > Torsten Wagner writes: > >> Using [Orgmode] as a tag on the orgmode list is an arguable point. >> Maybe the someone higher in the queue like to make a decision to >> shorten it to [Org]. > > I agreed this would be an improvement to use [Org]. > > If nobody have a strong objection, I'll make this change in two days. FWIW, I do. Having [Org] (or anything, really) prepended to the subjects of _all_ mails coming from a list that is already uniquely identifiable (e.g. by its address) has no information value altogether (unlike [Babel], [PATCH] etc.) and only takes up the much precious Subject: header space. I have never understood why anyone would like anything like that. If you want to somehow treat the mails from this list specially, why don't you filter on the presence of the mailing list address in the headers, for example? Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: elisp code takes CPU too much
Jambunathan K writes: >> hi. I have wrote an elisp code for org-mode, which puts entries in a >> table. It is a simple code in my opinion and it does the job I >> intended. But when executed, the activation of CPU shoots up and it >> will take a while to complete it. I do not believe that this little >> code requires such a work-load for the computer. There must be my >> wrong-doing. > > You have an infinite loop. The predicate of the while loop would always > evaluate to 'true' and never become 'false'. > >> Could anyone help me for fixing it? > > Try the following snippet with suitable variations. > > (setq word-list (list "apple" "orange" "lemon" "baseball" "football")) > > (defun test-table (word-list) > (let ((line 0) (column 3)) > (mapcar (lambda (word) > (org-table-put i column word t)) > word-list))) Unless you're going to do something with the list returned by this function (seems unlikely given that `org-table-put' doesn't seem to return anything useful), you should use `mapc' or `dolist' instead of `mapcar'. Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [BUG] Table field clipping doesn't handle double-width characters properly
Take the following table for instance:
| Year | English title | Korean title
| Transliterated title |
|--+++--|
| 1996 | Crocodile | 악어
| Ag-o |
| | Wild Animals | 야생동물 보호구역 |
Yasaeng dongmul bohoguyeog |
| 1998 | Birdcage Inn | 파란 대문
| Paran daemun |
| 2000 | The Isle | 섬
| Seom |
| | Real Fiction | 실제 상황
| Shilje sanghwang |
| 2001 | Address Unknown| 수취인 불명
| Suchwiin bulmyeong |
| | Bad Guy| 나쁜 남자
| Nabbeun namja|
| 2002 | The Coast Guard| 해안선
| Haeanseon|
| 2003 | Spring, Summer, Fall, Winter... and Spring | 봄, 여름, 가을, 겨울 그리고 봄 | Bom
yeoreum gaeul gyeoul geurigo bom |
| 2004 | Samaritan Girl | 사마리아
| Samaria |
| | 3-Iron | 빈 집
| Bin-jip |
| 2005 | The Bow| 활
| Hwal |
| 2006 | Time | 시간
| Shi gan |
| 2007 | Breath | 숨
| Soom |
| 2008 | Dream | 비몽
| Bimong |
If you add a width declaration ("") to the column containing Korean,
when realigning the table you'll get an "args out of range" error inside
the text-properties-related code in `org-table-align' (provided the
width declaration actually does cause the text to be clipped).
Štěpán
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Questions about org-capture templates and usage
Carsten Dominik writes: > Hi Nick, > > On Dec 6, 2010, at 3:48 PM, Nick Dokos wrote: > >> Alan E. Davis wrote: >> >>> >>> I have org-capture assigned to C-c, so C-u C-u C-c c goes straight to the >>> last stored item. Perfect. >> >> I presume the first `C-c' above is a typo and that the bindind is `C-c >> c', as the second instance indicates. Rebinding C-c to a command would >> be a disaster, but even C-c c is generally not a good idea: > > The way I see it: C-c belongs to the user, so it is a good key > for a global binding to org-capture if the user chooses > it - just like the documentation recommends. Org mode does not > enforce this key, it just recommends it. Indeed. More precisely, C-c belongs to the user, so `C-c c' is a perfectly fine user binding (and so is thus the suggestion in the docs). Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BUG] Table formula with org-hh:mm-string-to-minutes
Sébastien Vauban writes: > Hello, > > I use the following table and formulas to convert HH:MM times to fractional > times, so that I can sum up the times (and convert them to money...) > > | Task | *HH:MM* | *Frac* | > |+-+| > | Item 1 | 20:27 | 20.45 | > | Item 2 |2:25 | 2.42 | > | Item 3 |2:07 | 2.12 | > | Item 4 |0:19 | 0.00 | > | Item 5 |0:43 | 0.72 | > | Item 6 |0:05 | 0.08 | > | Item 7 |0:32 | 0.53 | > | Item 8 |0:16 | 0.27 | > |+-+| > || | 26.59 | > #+TBLFM: $3='(/ (float (org-hh:mm-string-to-minutes $2)) > 60.);%.2f::@5$3=0.00;%.2f::@10$3=vsum(@-...@-ii) I don't really understand Calc and Org table formulas, but the "%.2f::@5$3=0.00;" in there looks pretty suspicious, and removing it fixes it for me. ;-) Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Rainer M Krug writes: > Just one additional question: When I go on the menu to Org -- Documentation > -- Info Documentation, I still get the info help from version 6.21b, > although I installed the version from git, and under Org -- Documentation -- > Show Version it gives me "Org-mode version 6.36trans > (release_6.36.408.g7f21f)". > > Can I change this somehow? It seems that the Info Documentation is the one > which is part of emacs. That depends on your Emacs installation specifics. In short, the problem is that the directory containing the older Org documentation comes first in `Info-directory-list'. Reading the docstrings for this variable as well as `Info-default-directory-list' should give you enough information to come up with a solution suitable for your configuration. HTH, Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Make sure `flet' is fbound when executing `org-write-agenda'.
David Maus writes: > * org-agenda.el (org-write-agenda): Make sure `flet' is fbound > at runtime. > --- > lisp/org-agenda.el |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el > index 8035add..957bbf2 100644 > --- a/lisp/org-agenda.el > +++ b/lisp/org-agenda.el > @@ -2464,6 +2464,8 @@ higher priority settings." > beg (or (next-single-property-change beg 'org-filtered) > (point-max >(run-hooks 'org-agenda-before-write-hook) > + ;; make sure flet is fbound at runtime > + (unless (fboundp 'flet) (require 'cl)) >(cond > ((org-bound-and-true-p org-mobile-creating-agendas) > (org-mobile-write-agenda-for-mobile file)) This, while being an obvious (and correct) solution, is unfortunately not suitable for Emacs core. You're not supposed to require the cl package at runtime (you even get a compiler warning if you do). Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bug: org-capture destroys target file when user aborting prompt in template [6.36trans (release_6.36.430.gec51)]
David Maus writes: > [...] there is one of those ##-file (how are > those called?) [...] Those are called auto-save files. (info "(emacs)Auto Save Files") Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Carsten Dominik writes: > On Jun 26, 2010, at 6:30 PM, Štěpán Němec wrote: > >> "Eric Schulte" writes: >> >>> Štěpán Němec writes: >>> >>> [...] >>>> >>>> How come some of your rewrites above still use the `org-babel-' >>>> prefix? >>>> (As a side note, I don't see what Emacs guidelines suggest `ob-' >>>> is more >>>> appropriate than `org-babel-', and I would personally prefer to retain >>>> the latter -- it's much more descriptive.) >>>> >>>>Štěpán >>>> >>> >>> Hi Štěpán, >>> >>> The guidelines I mentioned (I believe) specify that all file names for >>> emacs-lisp files which are part of Emacs must be unique in the first 6 >>> or so characters. This is why all "(require 'ob-*)" lines (which must >>> correspond to file names) now use ob-* instead of org-babel-*. Since I >>> (like you) prefer the org-babel-* prefixes, those have been retained for >>> all function and variable names. >> >> I see. Hm... could you provide some source for that? The only >> restriction on file names I can recall is this section from Appendix D >> of the Emacs Lisp Reference Manual: >> >> * Please keep the names of your Emacs Lisp source files to 13 >> characters or less. This way, if the files are compiled, the >> compiled files' names will be 14 characters or less, which is >> short enough to fit on all kinds of Unix systems. > > This is a restriction from the compiler. > > However, Emacs wants to be installable on many systems, including MS- > DOS, which has only 8+3 character file names. Therefore, Emacs requires that > the names are unique in the first 8 letters - they may be longer than 8, but > they must be unique when shortened. > > I cannot find the reference now, but I did explicitly ask a short while ago > and got this confirmed by Stefan Monnier. Ah, right, I remember that, yes. MS-DOG strikes again. >> Is that perhaps what you meant? In any case, I see that the >> recommendation I quote above would make the file renaming necessary, >> too. >> >> (Also, I believe you actually did mention renaming *functions*, which >> created my confusion in the first place -- cf. the commit message of >> e0e4d76094f26 for example.) >> >>> Hope this explains it, I'm certainly open to other naming suggestions. >> >> It would make a lot of sense to at least still begin the file names with >> `org' IMHO, if at all possible. > > This will not solve the problem, I fear. Indeed. In this light `ob-' looks more like "as good as it gets". Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
"Eric Schulte" writes: > Štěpán Němec writes: > > [...] >> >> How come some of your rewrites above still use the `org-babel-' prefix? >> (As a side note, I don't see what Emacs guidelines suggest `ob-' is more >> appropriate than `org-babel-', and I would personally prefer to retain >> the latter -- it's much more descriptive.) >> >> Štěpán >> > > Hi Štěpán, > > The guidelines I mentioned (I believe) specify that all file names for > emacs-lisp files which are part of Emacs must be unique in the first 6 > or so characters. This is why all "(require 'ob-*)" lines (which must > correspond to file names) now use ob-* instead of org-babel-*. Since I > (like you) prefer the org-babel-* prefixes, those have been retained for > all function and variable names. I see. Hm... could you provide some source for that? The only restriction on file names I can recall is this section from Appendix D of the Emacs Lisp Reference Manual: * Please keep the names of your Emacs Lisp source files to 13 characters or less. This way, if the files are compiled, the compiled files' names will be 14 characters or less, which is short enough to fit on all kinds of Unix systems. Is that perhaps what you meant? In any case, I see that the recommendation I quote above would make the file renaming necessary, too. (Also, I believe you actually did mention renaming *functions*, which created my confusion in the first place -- cf. the commit message of e0e4d76094f26 for example.) > Hope this explains it, I'm certainly open to other naming suggestions. It would make a lot of sense to at least still begin the file names with `org' IMHO, if at all possible. Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
"Eric Schulte" writes:
> Hi Rainer,
>
> First I'll give some expanded instructions in the hopes of helping out
> anyone else affected by my lack of good instructions in the announcement
> email. Then I'll provide a re-write of your config below as an example.
>
> Babel took the integration into Org-mode as an opportunity to do some
> much needed house cleaning. Most importantly we have cleared out
> unnecessary configuration variables -- which is great unless you already
> have these variables set.
>
> We have eliminated the two main internal lists of languages, namely
> - org-babel-interpreters and
> - org-babel-tangle-langs
> so any config lines which mention those variables, can/should be
> stripped out in their entirety. This includes any calls to the
> `org-babl-add-interpreter' function, whose sole purpose was to add
> languages to the org-babel-interpreters variable.
>
> alright, so with those calls stripped out, we may still in some cases
> want to associate a file name extension with certain languages, for
> example we want all of our emacs-lisp files to end in a ".el", we can do
> this will the `org-babel-tangle-lang-exts' variable. In general you
> shouldn't need to touch this as it already has defaults for most common
> languages, and if a language is not present in org-babel-tangle-langs,
> then babel will just use the language name, so for example a file of c
> code will have a ".c" extension by default, sh code will have a ".sh"
> extension ect...
>
> You also mentioned shebang lines. This configuration now lives in
> header arguments. So the shebang for a single file can be set at the
> code block level, e.g.
>
> #+begin_src clojure :shebang #!/usr/bin/env clj
> (println "with a shebang line, I can be run as a script!")
> #+end_src
>
> note that whenever a file is tangled which includes a shebang line,
> org-babel will make the file executable, so there is good reason to only
> add shebangs at the source-code level. However if you're sure that you
> want all of your code in some language (say shell scripts) to tangle out
> with shebang lines, then you can customize the default header arguments
> for that language, e.g.
>
> ;; ensure this variable is defined defined
> (unless (boundp 'org-babel-default-header-args:sh)
> (setq org-babel-default-header-args:sh '()))
>
> ;; add a default shebang header argument
> (add-to-list 'org-babel-default-header-args:sh
> '(:shebang . "#!/bin/bash"))
>
> The final change, is that to conform to Emacs guidelines, the prefix
> org-babel-* in all require lines, has been changed to ob-*, also, since
> Babel now loads by default with Org-mode you can remove any
> (require 'org-babel)
> or
> (require 'org-babel-init)
> that may by lying around your configuration.
>
> Whew! that was alot of writing for a /simplification/ of configuration.
> Hopefully the example of your configuration below will be a more
> succinct demonstration of the needed transformations.
>
> Rainer M Krug writes:
>
>> Hi
>>
>> First of all thanks for integrating Org-babel into Org-mode.
>>
>> But for the less fluent elisp and org-mode users, I am slightly confused in
>> the changes necessary on my side.
>>
>> I have the following in my emacs.org file:
>>
>>
>> #+begin_src emacs-lisp
>> (require 'org-babel-R) ;; requires R and ess-mode
>> ;; (require 'org-babel-ruby) ;; requires ruby, irb, ruby-mode, and
>> inf-ruby
>> (require 'org-babel-python);; requires python, and python-mode
>> ;; (require 'org-babel-clojure) ;; requires clojure, clojure-mode,
>> swank-clojure and slime
>> #+end_src
>
> the above becomes
>
> #+begin_src emacs-lisp
> (require 'ob-R)
> ;; (require 'ob-ruby)
> (require 'ob-python)
> ;; (require 'ob-clojure)
> #+end_src
>
>>
>> *** Start babel
>> #+begin_src emacs-lisp
>> (org-babel-load-library-of-babel)
>> #+end_src
>
> the above becomes
>
> #+begin_src emacs-lisp
> (org-babel-lob-ingest "~/path/to/org/contrib/babel/library-of-babel.org")
> #+end_src
>
>>
>> *** Customization of sh
>> set shebang for sh script to "#!/bin/bash" and exclude additional comments
>> (t)
>> #+begin_src emacs-lisp
>> (setq org-babel-tangle-langs
>> (cons
>> '("sh" "sh" "#!/bin/bash" t)
>> (remove-if (lambda (el) (string= (car el) "sh")) org-babel-tangle-langs)))
>> #+end_src
>
> #+begin_src emacs-lisp
> ;; ensure this variable is defined defined
> (unless (boundp 'org-babel-default-header-args:sh)
> (setq org-babel-default-header-args:sh '()))
>
> ;; add a default shebang header argument
> (add-to-list 'org-babel-default-header-args:sh
>'(:shebang . "#!/bin/bash"))
> #+end_src
>
>>
>> *** Customization of R
>> set shebang for R script to "" and exclude additional comments (t)
>> #+begin_src emacs-lisp
>> (setq org-babel-tangle-langs
>> (cons
>> '("R" "R")
>> (remove-if (lambda (el) (string= (car el) "R")) org-babel-tangle-langs)))
>> #+end_src
>>
>
> the above can be omitted enti
[Orgmode] Re: [babel] Re: Re: [OT] gnuplot quality
Eric S Fraga writes: > I am surprised, however, at this comment: > >> Gnuplot was ok when I didn't need quailty graphs. > > in what way does gnuplot fall short in terms of quality? (but keep > this part of the conversatino off-list please to avoid annoying others) I can't speak for others, but I'm very interested in this and have found the suggestions in the thread very useful, so please keep it on-list! After all, a lot of Org users (will) need some kind of plotting solution, so this kind of discussion is naturally useful to them. After all, disregarding unwanted e-mails is definitely easier than getting to see the off-list ones ;-) Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Emacs 22 support - use org-string-match-p
On Thu, Jun 03, 2010 at 06:09:53PM -0400, Bernt Hansen wrote: > > Ehrm... do you really want to replace `string-match', too? > > Yes ... because it originally was a string-match-p that Carsten > converted to string-match since Emacs 22 doesn't have a string-match-p > during an earlier bug report (by me). > > Now that Carsten created org-string-match-p I'm just putting it back > closer to the original code. I see; thanks and sorry for the noise, Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Emacs 22 support - use org-string-match-p
Hello, sorry for being difficult again ;-) Bernt Hansen writes: [snip] > -(string-match "^//" str)) > +(org-string-match-p "^//" str)) Ehrm... do you really want to replace `string-match', too? [snip] Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Emacs 22 support
Bernt Hansen writes: > * contrib/lisp/org-special-blocks.el: Emacs 22 doesn't have string-match-p > --- > This patch is available at git://git.norang.ca/org-mode.git emacs22 > > contrib/lisp/org-special-blocks.el |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/contrib/lisp/org-special-blocks.el > b/contrib/lisp/org-special-blocks.el > index af50b30..4a2bc3c 100644 > --- a/contrib/lisp/org-special-blocks.el > +++ b/contrib/lisp/org-special-blocks.el > @@ -51,7 +51,7 @@ seen. This is run after a few special cases are taken care > of." >(when (or htmlp latexp) > (goto-char (point-min)) > (while (re-search-forward "^#\\+\\(begin\\|end\\)_\\(.*\\)$" nil t) > - (unless (string-match-p org-special-blocks-ignore-regexp (match-string 2)) > + (unless (string-match org-special-blocks-ignore-regexp (match-string 2)) > (replace-match >(if (equal (downcase (match-string 1)) "begin") >(concat "ORG-" (match-string 2) "-START") I didn't look at the code, but I doubt this is correct. The whole point of using `string-match-p' is to not affect the match data, so I would expect this change to possibly break the immediately following (match-string 1) etc. (depending on the exact regexp of course -- as I say I didn't actually check it, but in any case this is not a safe change AFAIK). You could try wrapping the `string-match' form inside `save-match-data' to prevent that. Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Agenda view > Day separator
Sébastien Vauban writes: >> [If that happens, please change (string-to-char "_") to ?_ >> Elisp has read syntax for characters, so you're making an unnecessary >> function call.] > > Thanks for the tip. FMI, is that valid in XEmacs as well -- even if I'm not > especially using it, I always try to be as most portable as possible. Yes, that is the proper way to write it in XEmacs as well. Štěpán > > Best regards, > Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Agenda view > Day separator
Sébastien Vauban writes: > (setq org-agenda-format-date > (concat "%Y-%m-%d %a " > (make-string (- (window-width) 15) (string-to-char "_" > > Carsten, maybe this could be made the default value? I guess it would help > people out there, when using the default config. Just a suggestion, I don't > mind setting it myself in my .emacs. [If that happens, please change (string-to-char "_") to ?_ Elisp has read syntax for characters, so you're making an unnecessary function call.] Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: spreadsheet table limitations, specifically summing hours?
oinksoc...@letterboxes.org writes: > (I'm starting to think it's going to need some test cases, and I'll need to > polish my elisp somewhat to find out how to do that. Are there any suggested > unit-testing schemes for elisp?) http://news.gmane.org/group/gmane.emacs.devel/thread=122140 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Frequently used files/headings
Stephan Schmitt writes: > Hi Nathan, > > when the lambda form is evaluated (when you press f6) the variable > shortcut-def doesn't exist any more. > > The problem is that elisp doesn't support closures. See > this info page: > (elisp) Top > Variables > Variable Scoping > Extent > > As a workaraound you can save the table in a global variable with setq > and access that variable in the lambda form. Another way would be to use `lexical-let' from the CL package, i.e.: (global-set-key (read-kbd-macro (second shortcut-def)) (lexical-let ((shortcut-def shortcut-def)) (lambda () (interactive) (org-id-goto (third shortcut-def) should do what you want. Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Frequently used files/headings
Nathan Neff writes: > I tried something like this, but all I get is "Wrong type argument: > integer-or-marker-p, (quote (second shortcut-def))" > > #+srcname: map-nav(navigation-shortcuts=navigation-shortcuts) > #+begin_src emacs-lisp > (defun map-navigation-shortcuts (shortcut-def) > (global-set-key (kbd (second shortcut-def)) (lambda () "Goto Foo Org File" > (interactive) > (org-id-goto '(third shortcut-def) > > (mapcar #'map-navigation-shortcuts navigation-shortcuts) > > #+end_src > > Can anyone point out where I'm going wrong? I haven't tried your code, but the way you call `kbd' is obviously wrong. `kbd' is a macro and does not evaluate its arguments; try using `read-kbd-macro' instead. HTH, Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Vim folding/syntax highlighting?
Michael Brand writes: > Hi Nathan > > Does it matter for you if the modal (i/ESC etc.) editor with the vi key > bindings that you like to use is run by Vim or Emacs? If not, then you can use > Emacs with viper-mode as a minor mode for the emulation of the vi key bindings > together with org-mode as the major mode. This is how I use Emacs and it feels > just like a Vim that would have the full implementation of the org-mode and > more. > > See also here: > http://www.gnu.org/software/emacs/manual/html_node/viper/index.html > http://thread.gmane.org/gmane.emacs.orgmode/17508 ...and (if you really want Vim, not Vi) here: http://www.emacswiki.org/emacs/?action=browse;id=Vimpulse ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Copying and Pasting (and Selecting)
David Frascone writes: > I didn't like org-refile. It didn't seem to want to refile under anything > but a top level (or maybe I was refiling a level 2) . . . I'll try to play > with it some more, but it didn't make my cheat sheet of cool tricks :) You have to adjust the `org-refile-targets' setting -- by default, it only lets you refile to top-level headings. With this, for instance: (setq org-refile-targets '((nil . (:maxlevel . 5 ... you'll be able to refile anywhere in the buffer up to 5th level. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: `org-refile' doc string
Nick Dokos writes: > Štěpán Němec wrote: > >> >> In the documentation of `org-refile' we read: >> >> If there is an active region, all entries in that region will be moved. >> However, the region must fulfil the requirement that the first heading >> is the first one sets the top-level of the moved text - at most siblings >> below it are allowed. >> >> >> I completely fail at parsing the second sentence. Could please someone >> who knows what it's trying to say fix it? >> > > What's the problem? It's crystal clear! :-) > > But seriously, I think what's it's trying to say is that you can't just > select an arbitrary region of the org file and refile it: it has to > satisfy some constraints. For example, if you start at a level 2 headline, > the region cannot then include a level 1 headline further down; it can only > include level 2 and lower headlines. > > The error message from the function when you try something illegal is > much clearer than the long explanation above: > > "The region is not a (sequence of) subtree(s)" > > Maybe the doc string should say: > > ... However, the region must satisfy some constraints: it has to be > a subtree (or a sequence of subtrees). > > Would that be clear enough? Clear enough for me to understand at least, thanks! An alternative and more verbose wording could be something like: However, the region must fulfil the requirement that all the included headings are on the same level as the first one or below (i.e. a subtree or sequence of subtrees). Best, Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] `org-refile' doc string
In the documentation of `org-refile' we read: If there is an active region, all entries in that region will be moved. However, the region must fulfil the requirement that the first heading is the first one sets the top-level of the moved text - at most siblings below it are allowed. I completely fail at parsing the second sentence. Could please someone who knows what it's trying to say fix it? Many thanks, Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Macro for begin_src?
Dan Davison writes: > I guess, for Nate's original application (converting existing code to > src blocks), what might have been most useful is something to enclose a > given region in a source block. Can anyone show how to do that with > yasnippet (or anything else)? I don't have a ready-to-use snippet, but this is what you need: http://yasnippet.googlecode.com/svn/trunk/doc/snippet-development.html#yas-wrap-around-region HTH, Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Macro for begin_src?
Dan Davison writes: >> Thanks! I'm having trouble triggering the yasnippets using the TAB key, so > I'm >> just using the GUI menu. >> >> Do you literally type "src" (no quotes), then press Tab? > > Yeah, but there's some magic code needed, which is also on Bernt's > page. > > (add-hook 'org-mode-hook > (lambda () > ;; yasnippet > (make-variable-buffer-local 'yas/trigger-key) > (setq yas/trigger-key [tab]) > (define-key yas/keymap [tab] 'yas/next-field-group))) I'm guessing what you really want there is (set (make-local-variable 'yas/trigger-key) [tab]) instead of > (make-variable-buffer-local 'yas/trigger-key) > (setq yas/trigger-key [tab]) The difference is that in the latter case you're making `yas/trigger-key' be automatically buffer-local for *all* buffers, not only in the buffer you're setting it (see e.g. the docstring of `make-variable-buffer-local'). Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Subscribing without receiving mail (was: Re: [PATCH] followup to "`org-rember-templates' docstring")
Bernt Hansen writes: > Carsten Dominik writes: > >> Hi Stepan >> On Apr 16, 2010, at 12:23 AM, Štěpán Němec wrote: >> >>> >>> Hello, >>> >>> I'm sorry for my somewhat precocious previous mail (which I >>> unfortunately still don't see posted, I use Gmane and am not >>> subscribed >>> -- any chance of making the list not moderated?). >> >> No, we like it spam free here. Please subscribe, if you don't want >> to receive the mails, use some throw-away web-based email address. > > Hi Štěpán, > > I also read org-mode through gmane and that's how I saw your original > posting about this problem. You can subscribe to the mailing list but > disable mail delivery and continue to read the list through gmane. > That's what I do and it works great. Thanks for this! Off-list Bernt also provided me with more detailed instructions. When you want to subscribe without automatically receiving any mail, first you have to subscribe as usual and then either log into the Mailman online interface and uncheck the `Mail delivery' option, or use the mailing interface, i.e. send an e-mail to emacs-orgmode-requ...@gnu.org with `help' in subject or body and follow the instructions (I did the former, the latter option is implied by the information e-mail sent to you upon subscribing). So, I'm still not a fan of subscribed-only mailing lists, but this is a viable compromise in this case. Thanks to all for help! Štěpán ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] followup to "`org-rember-templates' docstring"
Hello,
I'm sorry for my somewhat precocious previous mail (which I
unfortunately still don't see posted, I use Gmane and am not subscribed
-- any chance of making the list not moderated?).
I discovered that the documentation is corrected in org.texi.
I'm attaching a patch that fixes the original problem and some other
minor typos/errors.
>From 779ef7f69ed356539a961f4c27efb9256974e706 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?=
Date: Thu, 15 Apr 2010 22:49:39 +0200
Subject: [PATCH] Fix some minor typos and errors in the documentation.
- a few small typo fixes
- build -> built (where appropriate)
- overwrite -> override (where appropriate)
- unify todo / TODO usage (where appropriate)
- unify the `org-remember-templates' doc string and its texinfo
documentation (minor original differences not affecting semantics left in)
---
doc/org.texi | 28 ++--
lisp/org-remember.el | 41 ++---
2 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index d4a7be3..f4d3d3c 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -3808,7 +3808,7 @@ which should only be done in certain contexts, for example.
@section Priorities
@cindex priorities
-If you use Org mode extensively, you may end up enough TODO items that
+If you use Org mode extensively, you may end up with enough TODO items that
it starts to make sense to prioritize them. Prioritizing can be done by
placing a @emph{priority cookie} into the headline of a TODO item, like
this
@@ -3877,7 +3877,7 @@ with detailed subtasks on the t...@footnote{to keep subtasks out of the
global TODO list, see the @code{org-agenda-todo-list-sublevels}.}. To keep
the overview over the fraction of subtasks that are already completed, insert
either @samp{[/]} or @samp{[%]} anywhere in the headline. These cookies will
-be updates each time the todo status of a child changes, or when pressing
+be updated each time the TODO status of a child changes, or when pressing
@kbd{C-c C-c} on the cookie. For example:
@example
@@ -5871,7 +5871,7 @@ remember note was stored.
The Remember buffer will actually use @code{org-mode} as its major mode, so
that all editing features of Org mode are available. In addition to this, a
minor mode @code{org-remember-mode} is turned on, for the single purpose that
-you can use its keymap @code{org-remember-mode-map} to overwrite some of
+you can use its keymap @code{org-remember-mode-map} to override some of
Org mode's key bindings.
You can also call @code{org-remember} in a special way from the agenda,
@@ -5910,10 +5910,10 @@ path, it will be interpreted relative to @code{org-directory}.
The heading can also be the symbols @code{top} or @code{bottom} to send notes
as level 1 entries to the beginning or end of the file, respectively. It may
also be the symbol @code{date-tree}. Then, a tree with year on level 1,
-month on level 2 and day on level three will be build in the file, and the
+month on level 2 and day on level three will be built in the file, and the
entry will be filed into the tree under the current d...@footnote{if the file
contains an entry with a @code{DATE_TREE} property, the entire date tree will
-be build under that entry.}
+be built under that entry.}
An optional sixth element specifies the contexts in which the user can select
the template. This element can be a list of major modes or a function.
@@ -5934,7 +5934,7 @@ So for example:
@noindent
The first template will only be available when invoking @code{org-remember}
-from an buffer in @code{emacs-lisp-mode}. The second template will only be
+from a buffer in @code{emacs-lisp-mode}. The second template will only be
available when the function @code{my-check} returns @code{t}. The third
template will be proposed in any context.
@@ -5969,9 +5969,9 @@ allow dynamic insertion of content:
%x @r{Content of the X clipboard.}
%^C @r{Interactive selection of which kill or clip to use.}
%^L @r{Like @code{%^C}, but insert as link.}
+%k @r{title of the currently clocked task}
+%K @r{link to the currently clocked task}
%^g @r{prompt for tags, with completion on tags in target file.}
-%k @r{title of currently clocked task}
-%K @r{link to currently clocked task}
%^G @r{prompt for tags, with completion all tags in all agenda files.}
%...@{@var{pr...@}p @r{Prompt the user for a value for property @var{prop}}
%:keyword @r{specific information for certain link types, see below}
@@ -7753,7 +7753,7 @@ If you configure @code{org-agenda-diary-file} to point to an Org-mode file,
Org will create entries (in org-mode syntax) in that file instead. Most
entries will be stored in a date-based outline tree that will later make it
easy to archive appointments from previous months/years. The tree will be
-build under an entry with a @code{DATE_
[Orgmode] `org-remember-templates' docstring
Hello,
in the documentation string of `org-remember-templates' we read:
[...]
%^t like %t, but prompt for date. Similarly %^T, %^u, %^U.
You may define a prompt like %^{Please specify birthday
%n user name (taken from `user-full-name')
[...]
The line with the supposed birthday example is obviously truncated (at
least it doesn't make much sense to me like this).
I'm sorry I didn't send a patch, but I'm not sure what exactly the
contents were supposed to be -- actually I'm rather curious about that,
so I hope someone can fix it.
Thanks,
Štěpán
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
