Re: [O] #+header keywords for #+call keyword?
Eric Schulte writes: > "Dieter Wilhelm, H." writes: > >> Dear (), >> >> I've got a rather long argument list and it doesn't look good to >> supply all the arguments in one line, could somebody please implement >> #+header arguments for #+call like in the following example? >> >> #+header: :var NO=(org-entry-get nil "Report_Dir") >> #+header: :var DIR=(org-attach-dir) >> #+call: ProvideReport()[:results silent] >> >> By the way, is it still true that the number of #+header keywords for >> code blocks is restricted to 5 #+header lines? I think this is also >> an unnecessary restriction. >> >> Thank you very much >> > > The #+call: line syntax is a shortened syntax for code blocks. They > recently got #+names, hopefully soon they will get #+header arguments as > well. In the interum, you can always use a code block > > #+header: :var NO=(org-entry-get nil "Report_Dir") > #+header: :var DIR=(org-attach-dir) > #+call: ProvideReport()[:results silent] > > can be replaced by > > #+header: :var NO=(org-entry-get nil "Report_Dir") > #+header: :var DIR=(org-attach-dir) > #+begin_src emacs-lisp :var result=ProvideReport() :results silent > result > #+end_src I see, thank you, your suggestion is a already a good workaround for my needs. :-) Could you please also tell me whether you know of any restrictions concerning the number of #+header lines before a code block? -- Best wishes H. Dieter Wilhelm Darmstadt Germany
Re: [O] Encoding Problem in export?
Hi Nicolas,
Hi Nick,
At Wed, 24 Jul 2013 13:09:05 +0200,
Nicolas Goaziou wrote:
>
> Hello,
>
> Nick Dokos writes:
>
> > Maybe the thing to do is to delete '=' from org-link-escape-chars and
> > see what problems arise.
>
> AFAICT, `url-encode-url' is subtler than that. It encodes characters
> whenever they are really forbidden, which is not the case of
> `org-link-escape'. Hence my initial question: do we need to reinvent the
> wheel?
>
> > But I did find that '%' was originally in org-link-escape-chars and
> > David Maus hardcoded it (commit 139cc1d4), so that it is *always*
> > escaped.
>
> I Cc David Maus in case he has time to enlighten us about his choice.
>
IIRC org-link-escape is not used to create URLs but to escape
characters in a link that would otherwise conflict with Orgmode syntax
(e.g. square brackets). Org applies percent escaping to a link before
it is stored in the buffer and applies unescaping when it reads a link
back.
The percent sign is hardcoded because if org-link-escape/unescape is
used in this way we must make sure that the identity of a link is
preserved. If we would *not* escape the percent sign, then an original
link with percent encoded characters would be read back wrongly,
i.e. with the percent escaped characters unescaped.
This broke links.
E.g. consider a redirector link to the target url
`http://target.example.org?id=33&format=html";':
,
|
http://redirect.example.org?url=http%3A%2F%2Ftarget.example.org%3Fid%3D33%26format%3Dhtml
`
If we don't escape the percent sign but apply unescaping when, say,
the user opens the link we would get:
,
| http://redirect.example.org?url=http://target.example.org?id=33&format=html
`
And voila: The `format' parameter is turned into a query parameter of
redirect.example.org, not target.example.org.
The specs (RFC3986) have to say the following about escaping:
,
|Because the percent ("%") character serves as the indicator for
|percent-encoded octets, it must be percent-encoded as "%25" for that
|octet to be used as data within a URI. Implementations must not
|percent-encode or decode the same string more than once, as decoding
|an already decoded string might lead to misinterpreting a percent
|data octet as the beginning of a percent-encoding, or vice versa in
|the case of percent-encoding an already percent-encoded string.
`
There is, of course, the nasty thing that we don't know if the link in
a buffer went through org-link-escape or not. E.g. if you paste
,
|
[[http://redirect.example.org?url=http%3A%2F%2Ftarget.example.org%3Fid%3D33%26format%3Dhtml]]
`
into the buffer you'll get a broken link because org-link-open assumes
the link to be escaped by org.
The bottom-line: Org creates link programmatically (org-store-link)
and needs a mechanism to protected conflicting characters. It chose
percent-escaping and in order to preserve the identity of a link Org
has to escape the escape-character.
Hope that helps!
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
[O] Auto insert and change date in header?
Hi list does any one know of a way to auto insert/change the date in each sections header when the section is edited?IE have a date in the header showing last edited date. Is this technically possible? best Z
Re: [O] Import files to babel blocks
Hi Myles, On 7/21/13 12:31 PM, Myles English wrote: > > From the documentation (C-h f insert-file-contents), it says that it > "returns list of absolute file name and number of characters" but > doesn't move the marker forwards, unlike insert does. So, I guess you > would have to then move the marker forwards by the number of characters. > Erhm, another case of readthedocs... Thanks for the shove! For reference, I got it to work using a simple let like so: --8<---cut here---start->8--- (defun import-to-org-from-files (path pattern progmode) (mapcar #'(lambda (filepath) (progn (insert (format "\n#+name: %s\n" (file-name-nondirectory (file-name-sans-extension filepath (insert (format "#+begin_src %s :eval no\n" progmode)) (let ((res (insert-file-contents filepath))) (forward-char (second res))) (insert "\n#+end_src\n")) ) (directory-files path t pattern))) --8<---cut here---end--->8--- much obliged, Michael
Re: [O] [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
Torsten Wagner writes: > Hi Rick, Hi Sebastien, > > thanks for your inputs. > Well I guess Sebastien is half-right. The different settings make at least > it even more tricky to see what is going on. > Here is a table with the settings as I found them on my system (which I did > not change) > > #+BEGIN_ORG > > | org-babel-default-header-args| ((:session . "none") (:results . > "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines . > "no") (:tangle . "no") (:padnewline . "yes")) | > | org-babel-default-lob-header-args| ((:exports . > "results")) > | > | org-babel-default-inline-header-args | ((:session . "none")(:results . > "replace")(:exports . > "results")) > | > > #+END_ORG > > As you can see the most prominent cause for trouble might be :hlines > As Rick should in his message it does still not solve all problems but it > helps to make it more clear. > This is related to http://thread.gmane.org/gmane.emacs.orgmode/73976/focus=74175. > > I assume Eric is on holiday or otherwise busy but I guess he will find this > thread and might can give us some idea, whether there was an intention in > dealing with tables in that way or whether it is really considered as a bug. > Yes, I've been very busy. > > However, Sebastian pointed out a very important fact. Different default > settings for different ways of calling a source code block. I believe that > this should find its way into the manual. > I'm happy to apply patches to the manual. > > All the best > > Torsten > > > > > On 22 July 2013 13:20, Torsten Wagner wrote: > >> Hi, >> >> I want to summarize the problem I found, using tables as input to source >> code blocks. >> This observation was shared with Rick and I would be glad to help fixing >> that. >> >> Within the attached file one can see a typical example. >> >> It all comes down to a differently interpretation of tables with respect >> to horizontal line. >> >> #+TBLNAME: with-hline >> | A | B | C | >> |---+---+---| >> | 1 | 2 | 3 | >> | X | Y | Z | >> >> and >> >> #+TBLNAME: without-hline >> | A | B | C | >> | 1 | 2 | 3 | >> | X | Y | Z | >> >> will give different results being called by >> >> #+name: python-element >> #+begin_src python :var table=with-hline :exports results >> return table[1] >> #+end_src >> >> or >> >> #+CALL: python-echo(with-hline) >> >> Please see the attached file for details. >> >> From what I was able to observe: >> >> 1. Calling a table with hline, the result of the source code block miss >> the first row. Indexing is possible only for the second and third row (in >> the given example) >> >> 2. Having no hline, the first row is available, indexing of the first row >> works too. >> >> Using a Call construct: >> 1. for a table without hline, indexing works but it does not work for a >> table with hline. >> 2. Interestingly, using the CALL functions, the type of both tables in >> python is list for the entire table, however, indexing a table with hlines, >> the type becomes NoneType whereas for a table without hline it is still of >> type list. >> >> >> Hope that can somehow help to get an idea what is going on. >> >> >> Greetings >> >> Torsten >> >> >> >> >> >> -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] feature request: debug messages
Andreas Leha writes: > Andreas Leha writes: > >> Andreas Leha writes: >> >>> Hi Eric, >>> >>> >>> Eric Schulte writes: >>> Andreas Leha writes: > Hi Eric, > > > Eric Schulte writes: > >> Hi Andreas, >> >> This should be easy to turn on or off using the newly introduced >> :prologue and :epilogue header arguments. See the manual and the >> following example. >> >> #+Title: debug messages >> #+Property: session *R* >> #+Property: prologue (format "print(\"entering %s\")" (get-current-name)) >> >> An elisp block to simplify the =:prologue= definition. >> #+begin_src emacs-lisp >> (defun get-current-name () >> (save-excursion >> (goto-char org-babel-current-src-block-location) >> (while (and (forward-line -1) >> (looking-at org-babel-multi-line-header-regexp))) >> (when (looking-at org-babel-src-name-w-name-regexp) >> (org-no-properties (match-string 3) >> #+end_src >> >> Two blocks with simple assignments. >> >> #+name: block-1 >> #+begin_src R >> x <- 2 + 2 >> #+end_src >> >> #+name: block-2 >> #+begin_src R >> y <- x + x >> #+end_src >> >> Execute the whole buffer =C-c C-v b= to see the prologue in action. >> >> Andreas Leha writes: >> >>> Hi all, >>> >>> I would love to see messages like 'entering block foo...' and >>> '...leaving block foo' printed to my R console. This would be very >>> handy when I evaluate a subtree (C-c C-v s) with a lot of #+call lines >>> and some lengthy ones. >>> >>> I know that >>> (1) I could implement that myself at in the source blocks. But I would >>> love if orgmode did that for me >>> (2) Such messages are already printed to the emacs *Messages* buffer. >>> But that buffer might not be visible and I can not switch to it, >>> without interrupting the evaluation. Anyway it would be much nicer >>> to see that output together with the other output, that my code >>> generates. >>> >>> >>> In essence it would be very helpful, if there was a variable >>> org-babel-print-debug-messages (or org-babel-debug-level...) which if >>> non-nil would cause that messages to be printed. Or is there somewhere >>> already? >>> >>> Regards, >>> Andreas >>> >>> >>> >>> > > > thanks for the quick answer! The :prologue and :epilogue header > arguments have indeed slipped my attention and they look really > interesting! I see, that they are documented, but somehow, they seem to > not get their headline and TOC entry? > > I have three problems with your example, though: > 1) It does not run > 2) It does not work > 3) It won't be usable for 'my' epilogue, correct? > ;-) > Ah! My fault. I had to add prologue and epilogue support to ob-R.el when working through the example I sent, but then I forgot to commit that support to Org-mode. I've just pushed up that commit, and re-worked my example file to avoid the issue of prologue being applied to the emacs-lisp code block (using the very nice and also new language-specific PROPERTY header arguments). Finally, I don't use epilogues in the example because (as the last thing evaluated) they would override the code block results. Hopefully the following: 1. will run 2. will work 3. will be usable Cheers, #+Title: debug messages #+Property: header-args:R :session *R* :prologue (format "print(\"entering %s\")" (get-current-name)) An elisp block to simplify the =:prologue= definition. #+begin_src emacs-lisp :results silent (defun get-current-name () (save-excursion (goto-char org-babel-current-src-block-location) (while (and (forward-line -1) (looking-at org-babel-multi-line-header-regexp))) (when (looking-at org-babel-src-name-w-name-regexp) (org-no-properties (match-string 3) #+end_src Two blocks with simple assignments. #+name: block-1 #+begin_src R x <- 2 + 2 #+end_src #+RESULTS: block-1 : 4 #+name: block-2 #+begin_src R y <- x + x #+end_src #+RESULTS: block-2 : 8 Execute the whole buffer =C-c C-v b= to see the prologue in action. > > 1) > It does not run, because org tries to do the prologue also on the > emacs-lisp block defining the function of the prologue. So, I get > "format: Symbol's function definition is void: get-current-name" > I changed the #+property line to > #+Property: header-args:R :prologue (format "print(\"entering %s\")" > (get-current-name)) > which solved that
Re: [O] how to quote "#+end_src" string in a Babel block?
asenal writes: > Hi Guys I'm trying to do literature programming with org mode. > My problem is How can I safely quote "#+XXX" inside a Babel-block? > I found org-mode mismatch the outter "#+begin_src" with the first > "#+end_src" inside the block hence gives me a wrong parse. > > Here's an example: > #+headers: :var varlist=top_iv > #+begin_src python :return iv_template(varlist) > def iv_template(varlist,db,table): > for var in varlist: > babel_template=''' > #+name: var > #+begin_src sqlite :db mydb > SELECT colName,cnt,suc,fal,iv FROM mytable WHERE colName == %s'; > #+end_src # org mode stop here! > ''' % (var,var) > > print babel_template > #+end_src > > I know it looks twisted,but what I really care is wheather org-mode > holds the capability to do so. > The following syntax should work. If you edit code blocks with C-' the leading ' characters will be added and stripped automatically. #+begin_src python :return iv_template(varlist) def iv_template(varlist,db,table): for var in varlist: babel_template=''' ,#+name: var ,#+begin_src sqlite :db mydb SELECT colName,cnt,suc,fal,iv FROM mytable WHERE colName == %s'; ,#+end_src # org mode stop here! ''' % (var,var) print babel_template #+end_src -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] #+header keywords for #+call keyword?
"Dieter Wilhelm, H." writes: > Dear (), > > I've got a rather long argument list and it doesn't look good to > supply all the arguments in one line, could somebody please implement > #+header arguments for #+call like in the following example? > > #+header: :var NO=(org-entry-get nil "Report_Dir") > #+header: :var DIR=(org-attach-dir) > #+call: ProvideReport()[:results silent] > > By the way, is it still true that the number of #+header keywords for > code blocks is restricted to 5 #+header lines? I think this is also > an unnecessary restriction. > > Thank you very much > The #+call: line syntax is a shortened syntax for code blocks. They recently got #+names, hopefully soon they will get #+header arguments as well. In the interum, you can always use a code block #+header: :var NO=(org-entry-get nil "Report_Dir") #+header: :var DIR=(org-attach-dir) #+call: ProvideReport()[:results silent] can be replaced by #+header: :var NO=(org-entry-get nil "Report_Dir") #+header: :var DIR=(org-attach-dir) #+begin_src emacs-lisp :var result=ProvideReport() :results silent result #+end_src Best, > > Dieter > -- > Best wishes > > H. Dieter Wilhelm > > Darmstadt > Germany > -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] #+header keywords for #+call keyword?
Dear Dieter Wilhelm, I do not know a way to change the standard properties for a #+CALL construct. However, we recently discussed a problems with tables and source code calls. Sebastien pointed to the following variables. org-babel-default-header-args ((:session . "none") (:results . "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no") (:padnewline . "yes")) org-babel-default-lob-header-args ((:exports . "results")) org-babel-default-inline-header-args ((:session . "none")(:results . "replace")(:exports . "results")) You might want to change org-babel-default-lob-header-args to your needs. That could be done in a small eslip code block within an org-file and might at least helps as a intermediate solution All the best Torsten On 24 July 2013 14:11, Dieter Wilhelm, H. wrote: > Dear (), > > I've got a rather long argument list and it doesn't look good to > supply all the arguments in one line, could somebody please implement > #+header arguments for #+call like in the following example? > > #+header: :var NO=(org-entry-get nil "Report_Dir") > #+header: :var DIR=(org-attach-dir) > #+call: ProvideReport()[:results silent] > > By the way, is it still true that the number of #+header keywords for > code blocks is restricted to 5 #+header lines? I think this is also > an unnecessary restriction. > > Thank you very much > > Dieter > -- > Best wishes > > H. Dieter Wilhelm > > Darmstadt > Germany > >
Re: [O] Emacs-orgmode Digest, Vol 89, Issue 30
John Kitchin writes: > > This works if the unzipped directory images exists. In my case that won't be > true. > > What I am doing is creating a script that runs a python script, > captures any images created by matplotlib, creates an org-file, then > creates a zip-file that contains the org-file of the script, the > output, and links to the figures, as well as the figures. The zip-file > will then be submitted to a server, where the original images do not > exist. I can unzip the zip-file on the server, and it works fine, but > I was trying to avoid that. > Yup - you are right: I was a bit too cavalier in my testing. I don't know how to accomplish what you want. I'll think about it some more. -- Nick
Re: [O] Adding support for limits and exclusions to iCal recurring events
Nicolas Goaziou writes: > I'm clearly no Agenda specialist. I thought a DEADLINE would end > a repeated event already. If it's not the case, does it make sense to > implement it too? I consider DEADLINE, in our context, to mean "when my finished work will be needed", and therefore "when to start bothering me about getting it done". I think that was the intention when this system was set up; in other words, I think DEADLINE is treated as simply a personal warning system, and it doesn't have the power to modify the agenda like TODO vs DONE. -- David R
Re: [O] Orgmode fails to export specific web-links as latex/pdf
Hello, Bastien writes: > Nicolas Goaziou writes: > >> I will have a look at it, but this is not clear to me either. I still >> have to understand what should be escaped, and when. > > All right, no hurry! And thanks a lot in advance, I cannot reproduce the bug anymore. Can you? Regards, -- Nicolas Goaziou
Re: [O] Adding support for limits and exclusions to iCal recurring events
Michael Brand writes: > When implementing this, consider also whether the END_DATE should be > an agenda entry on its own and of which kind, warning period etc. I > tried to make an example that shows this issue. Adding to this, as mentioned previously, I interpret the iCal standard to really permit and end *time* rather than an end *date*. Which would make more sense in an org context? Going for an END_TIME parameter, and then comparing exactly to the scheduled time (i.e. if current iteration of the recurring entry > END_TIME, then filter it), or doing an END_DATE and then interpreting the actual cut-off to be at 00:00:00 on that date? -Toke signature.asc Description: PGP signature
Re: [O] Emacs-orgmode Digest, Vol 89, Issue 30
> -- Forwarded message -- > From: Nick Dokos > To: emacs-orgmode@gnu.org > Cc: > Date: Wed, 24 Jul 2013 04:50:36 -0400 > Subject: Re: [O] links to files in a zip archive and inline images in zip > archive > John Kitchin writes: > > > I am trying to make an org-mode zip archive. The idea is basically to > > zip up the org-file, and the images it might refer to. What I would > > really like is to be able to open the zip-file in emacs, and have the > > images shown inline like they are when the archive is expanded. > > > > I had no problem making the zip archive, and it opens fine in emacs. I > > can read the org file fine, but there are no inline images, and the > > links to the images do not work. > > > > It might be ok if the links in the org-file would open the images, but > > they do not do that either (I get cannot display image: cannot > > determine image type and a blank screen). > > > > Is this idea way off base? or is there a way to get it to work? I do > > not have to stick with zip archives if another format would work well. > > > My guess is that your links use absolute paths. I had no problem doing > this with a file using relative paths and the following directory > structure: > > tmp -- kitchin.org > `- images -- foo.png > > kitchin.org looks like this: > > --8<---cut here---start->8--- > #+STARTUP: inlineimages > > * foo > > This [[file:images/foo.png]] is an inline image. > --8<---cut here---end--->8--- > > and I zipped like this: > > $ zip kitchin.zip kitchin.org images > > I can then open the zip file, and open kitchin.org inside the zip file > with the inline image showing. > -- > Nick > > This works if the unzipped directory images exists. In my case that won't be true. What I am doing is creating a script that runs a python script, captures any images created by matplotlib, creates an org-file, then creates a zip-file that contains the org-file of the script, the output, and links to the figures, as well as the figures. The zip-file will then be submitted to a server, where the original images do not exist. I can unzip the zip-file on the server, and it works fine, but I was trying to avoid that. j
Re: [O] Adding support for limits and exclusions to iCal recurring events
Hi Nicolas On Wed, Jul 24, 2013 at 10:38 AM, Nicolas Goaziou wrote: > I'm clearly no Agenda specialist. I thought a DEADLINE would end > a repeated event already. No, DONE shifts it to the repeat date and like this it will never end. > If it's not the case, does it make sense to implement it too? In this case I would vote for to use a new property. An example like * TODO send weekly report DEADLINE: <2013-07-27 Sat 18:00 ++1w -1d> could then be terminated with * TODO send weekly report until end of terminated contract DEADLINE: <2013-07-27 Sat 18:00 ++1w -1d> END_DATE: <2013-12-31 Tue> When implementing this, consider also whether the END_DATE should be an agenda entry on its own and of which kind, warning period etc. I tried to make an example that shows this issue. Michael
Re: [O] org-forward-element looses selection on code blocks
Hello,
"Sebastien Vauban"
writes:
> Up to quite recently, I could select ("region") code blocks or multiple
> consecutive paragraphs by pressing which ran `forward-paragraph'.
>
> Now that is mapped to `org-forward-element':
>
> - I can't select any code block anymore via (well line by line with
> ).
> - I can't select consecutive paragraphs from following subtrees.
This second item is inherent to the structure of the document. You can
use `org-down-element' to move into the next subtree.
> Is there a plan to fix it in `org-forward-element' (IOW, do we consider that
> as a bug or a feature, or not at all?), or must I remap back to its
> old command?
I don't think the bug comes from `org-forward-element'.
If you use C-space in the middle of the block and then M-x
org-forward-element, the block will be marked. If you do the same with
C- instead of M-x org-forward-element, it will not be marked.
There is a similar problem with `org-end-of-line' (it will lose region
if called through C-e, but not with M-x org-end-of-line), also on source
blocks.
I don't know the root of this evil.
Anyhow, you can remap to whatever suits you.
Regards,
--
Nicolas Goaziou
[O] org-forward-element looses selection on code blocks
Hello,
Up to quite recently, I could select ("region") code blocks or multiple
consecutive paragraphs by pressing which ran `forward-paragraph'.
Now that is mapped to `org-forward-element':
- I can't select any code block anymore via (well line by line with
).
- I can't select consecutive paragraphs from following subtrees.
I think I can live with the latter, but I find the former very inconvenient.
Is there a plan to fix it in `org-forward-element' (IOW, do we consider that
as a bug or a feature, or not at all?), or must I remap back to its
old command?
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Latex export and missing PDF document properties
On Wed, Jul 24, 2013 at 01:47:21PM +0200, Dieter Wilhelm, H. wrote: > > the keywords > > #+keywords > #+description > > appear in PDF properties when query them under acrobat reader either > under windows or linux, but strangely not the following > > #+title > #+author > > I'm using pdfTeX-1.40.3 and Org mode 8.0.6 > $ pdfinfo Bfys_PhD_TD_Dalitz.pdf Title: Time-dependent Dalitz-plot formalism Author: Suvayu Ali (for PhD paper discussion) Creator:Emacs 24.3.50.1 (Org mode 8.0-pre) Producer: xdvipdfmx (0.7.8) CreationDate: Tue Apr 9 13:31:31 2013 Tagged: no Form: none Pages: 7 Encrypted: no Page size: 362.83 x 272.13 pts Page rot: 0 File size: 58931 bytes Optimized: no PDF version:1.5 This is what I get. My pdftex version is: pdfTeX 3.1415926-2.4-1.40.13 (TeX Live 2012) Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] auto pack empty space between headers?
thx bastian, you suggested this: I sometimes use this crude method: M-< C-M-% ^C-qC-jC-qC-j+ RET C-qC-j RET i cant seem to get it working, i always get a "replace 0 occurrences" message. to be clear i do the following: i press M-< (mark set?) then C-M-% (query reolace) then enter : ^C-qC-jC-qC-j+ (as the what to replace) and press return the replace with i enter: C-qC-j and press return and the message is replace 0 occurrences is that correct? appreciate your help as always On Sun, Jun 30, 2013 at 4:30 PM, Bastien wrote: > Hi Xebar, > > Xebar Saram writes: > > > i was > > wondering if there was any command to auto pack empty space between > > headers? > > I sometimes use this crude method: > > M-< C-M-% ^C-qC-jC-qC-j+ RET C-qC-j RET > > Otherwise you can tweak `org-blank-before-new-entry'. > > HTH, > > -- > Bastien >
Re: [O] style the tags with colors in theme
That is strange. It works for me and has being working for a long
time. For reference, my org-mode version is 8.06 and Emacs version is
24.3.50.2.
Maybe it is something related to you configuration. Try to start Emacs
with a different and minimum configuration including setting
org-tag-faces and see it that has an effect.
If it works, then you will need to bisect your configuration to isolate
what makes it stop working.
--
Darlan Cavalcante Moreira
darc...@gmail.com
zelt...@gmail.com writes:
> thx again for the answer but it dosent see to work here:
>
> https://paste.xinu.at/KlvP/
>
> this is what i have in my config:
>
> (setq org-tag-faces '(
> ("mru" :inherit org-done :box nil :underline t :height 1.2)
> ("Fav" :foreground "blue" :box nil :underline t :height
> 1.2)))
>
> i restarted emacs but still see fav as a regular tag with out a foreground
> of blue etc
>
> any ideas what im doing wrong?
>
> -
>
> The ATTACH tag is automatically added when I attach a file to a headline
> (see Attachments in the org-mode manual [[info:org#Attachments]]). It's
> the only tag I like to change appearance and thus I used it as an
> example. But the same procedure should work with other tags.
>
> A very important detail is that you need to restart Emacs. In the
> documentation of org-tag-faces it says "If you set it with Lisp, a
> restart of Emacs is required to activate the changes."
>
> Therefore, put something like the code below in your initialization file
> and restart Emacs and it should work
>
> --8<---cut here---start->8---
> (setq org-tag-faces '(
> ("SomeTag" :inherit org-done :box nil :underline t :height
> 1.2)
> ("SomeOtherTag" :foreground "blue" :box nil :underline t
> :height 1.2)))
> --8<---cut here---end--->8---
>
> I think that the tags don't need to be in org-tag-alist for this to
> work.
>
>
> On Tue, Jul 23, 2013 at 11:19 PM, Darlan Cavalcante Moreira <
> darc...@gmail.com> wrote:
>
>>
>> The ATTACH tag is automatically added when I attach a file to a headline
>> (see Attachments in the org-mode manual [[info:org#Attachments]]). It's
>> the only tag I like to change appearance and thus I used it as an
>> example. But the same procedure should work with other tags.
>>
>> A very important detail is that you need to restart Emacs. In the
>> documentation of org-tag-faces it says "If you set it with Lisp, a
>> restart of Emacs is required to activate the changes."
>>
>> Therefore, put something like the code below in your initialization file
>> and restart Emacs and it should work
>>
>> --8<---cut here---start->8---
>> (setq org-tag-faces '(
>> ("SomeTag" :inherit org-done :box nil :underline t
>> :height 1.2)
>> ("SomeOtherTag" :foreground "blue" :box nil :underline t
>> :height 1.2)))
>> --8<---cut here---end--->8---
>>
>> I think that the tags don't need to be in org-tag-alist for this to
>> work.
>>
>> --
>> Darlan Cavalcante Moreira
>> darc...@gmail.com
>>
>>
>> zelt...@gmail.com writes:
>>
>> > Thx Darlan but i cant seem to get it to work.
>> > i have tried both adding ATTACH in the top of my org file:
>> >
>> > #+TAGS: Fav(f) todo(t) mru(m) bind(b) ATTACH(a)
>> >
>> > and also in my org config:
>> >
>> > (setq org-tag-alist '(("@work" . ?w) ("@ATTACH" . ?a) ("@dl" . ?d)
>> ("@preR"
>> > . ?p) ("@fav" . ?f)("@linux" . ?l)))
>> >
>> > and added your line to my config yet nothing happned when i add the
>> ATTACH
>> > tag, what am i missing here?
>> >
>> > best
>> >
>> > z
>> >
>> >
>> >
>> >
>> > On Tue, Jul 23, 2013 at 2:45 PM, Darlan Cavalcante Moreira <
>> > darc...@gmail.com> wrote:
>> >
>> >> I use the code below for the ATTACH tag
>> >>
>> >> --8<---cut here---start->8---
>> >> (setq org-tag-faces '(("ATTACH" :inherit org-done :box nil :underline t
>> >> :height 1.2)))
>> >> --8<---cut here---end--->8---
>> >>
>> >> --
>> >> Darlan Cavalcante Moreira
>> >> darc...@gmail.com
>> >>
>> >>
>> >> b...@gnu.org writes:
>> >>
>> >> > Hi Xebar,
>> >> >
>> >> > Xebar Saram writes:
>> >> >
>> >> >> does anyone know how (if there is a way) to style the tags with
>> >> >> colors in a theme? IE to have tags with a different fg/bg from
>> >> >> default and even better yet to define a different color for each
>> >> >> tag?
>> >> >
>> >> > See this:
>> >> >
>> >> > C-h v org-tag-faces RET
>> >> >
>> >> > HTH,
>> >>
>>
[O] [BUG] (wrong-type-argument wholenump nil)
Hello, With a *minimal config file* and Org-mode version 8.0.6 (release_8.0.6-357-gf00d75 @ d:/Users/sva/Public/Repositories/org-mode/lisp/) there is a Lisp error generated when trying to split a block of code into two pieces through `C-c C-v C-d' (org-babel-demarcate-block). ECM: --8<---cut here---start->8--- #+begin_src sh ls ls #+end_src --8<---cut here---end--->8--- Steps to reproduce: 1. Put point on the second "ls" line 2. Press `C-c C-v C-d' Backtrace: --8<---cut here---start->8--- Debugger entered--Lisp error: (wrong-type-argument wholenump nil) make-string(nil 32) (let ((lang (nth 0 info)) (indent (make-string (nth 5 info) 32))) ...) ... org-babel-demarcate-block(nil) call-interactively(org-babel-demarcate-block nil nil) --8<---cut here---end--->8--- FYI, it works in an old Org version (such as 7.9.2+, bundled with GNU Emacs 24.2.91.1). Best regards, Seb -- Sebastien Vauban
[O] #+header keywords for #+call keyword?
Dear (), I've got a rather long argument list and it doesn't look good to supply all the arguments in one line, could somebody please implement #+header arguments for #+call like in the following example? #+header: :var NO=(org-entry-get nil "Report_Dir") #+header: :var DIR=(org-attach-dir) #+call: ProvideReport()[:results silent] By the way, is it still true that the number of #+header keywords for code blocks is restricted to 5 #+header lines? I think this is also an unnecessary restriction. Thank you very much Dieter -- Best wishes H. Dieter Wilhelm Darmstadt Germany
[O] Latex export and missing PDF document properties
Dear (), the keywords #+keywords #+description appear in PDF properties when query them under acrobat reader either under windows or linux, but strangely not the following #+title #+author I'm using pdfTeX-1.40.3 and Org mode 8.0.6 Am I missing something? By the way, the linux version seems to have problems with annotating and commenting. The same PDF forbids commenting under Linux (reader 9) and allows them under Windows (reader 11)!? -- Best wishes H. Dieter Wilhelm Darmstadt Germany
Re: [O] Encoding Problem in export?
Hello, Nick Dokos writes: > Maybe the thing to do is to delete '=' from org-link-escape-chars and > see what problems arise. AFAICT, `url-encode-url' is subtler than that. It encodes characters whenever they are really forbidden, which is not the case of `org-link-escape'. Hence my initial question: do we need to reinvent the wheel? > But I did find that '%' was originally in org-link-escape-chars and > David Maus hardcoded it (commit 139cc1d4), so that it is *always* > escaped. I Cc David Maus in case he has time to enlighten us about his choice. > I assume there is a good reason for that, but if so, url-encode-url > might not be enough - afaict, it leaves '%' signs alone: Yes, there is a comment in url-util.el: (defconst url-host-allowed-chars ;; Allow % to avoid re-encoding %-encoded sequences. (url--allowed-chars (append '(?% ?! ?$ ?& ?' ?\( ?\) ?* ?+ ?, ?\; ?=) url-unreserved-chars)) "Allowed-character byte mask for the host segment of a URI. These characters are specified in RFC 3986, Appendix A.") Not sure how it could affect URI correctness. I trust "url-util.el" authors, though. Regards, -- Nicolas Goaziou
Re: [O] style the tags with colors in theme
thx again for the answer but it dosent see to work here:
https://paste.xinu.at/KlvP/
this is what i have in my config:
(setq org-tag-faces '(
("mru" :inherit org-done :box nil :underline t :height 1.2)
("Fav" :foreground "blue" :box nil :underline t :height
1.2)))
i restarted emacs but still see fav as a regular tag with out a foreground
of blue etc
any ideas what im doing wrong?
-
The ATTACH tag is automatically added when I attach a file to a headline
(see Attachments in the org-mode manual [[info:org#Attachments]]). It's
the only tag I like to change appearance and thus I used it as an
example. But the same procedure should work with other tags.
A very important detail is that you need to restart Emacs. In the
documentation of org-tag-faces it says "If you set it with Lisp, a
restart of Emacs is required to activate the changes."
Therefore, put something like the code below in your initialization file
and restart Emacs and it should work
--8<---cut here---start->8---
(setq org-tag-faces '(
("SomeTag" :inherit org-done :box nil :underline t :height
1.2)
("SomeOtherTag" :foreground "blue" :box nil :underline t
:height 1.2)))
--8<---cut here---end--->8---
I think that the tags don't need to be in org-tag-alist for this to
work.
On Tue, Jul 23, 2013 at 11:19 PM, Darlan Cavalcante Moreira <
darc...@gmail.com> wrote:
>
> The ATTACH tag is automatically added when I attach a file to a headline
> (see Attachments in the org-mode manual [[info:org#Attachments]]). It's
> the only tag I like to change appearance and thus I used it as an
> example. But the same procedure should work with other tags.
>
> A very important detail is that you need to restart Emacs. In the
> documentation of org-tag-faces it says "If you set it with Lisp, a
> restart of Emacs is required to activate the changes."
>
> Therefore, put something like the code below in your initialization file
> and restart Emacs and it should work
>
> --8<---cut here---start->8---
> (setq org-tag-faces '(
> ("SomeTag" :inherit org-done :box nil :underline t
> :height 1.2)
> ("SomeOtherTag" :foreground "blue" :box nil :underline t
> :height 1.2)))
> --8<---cut here---end--->8---
>
> I think that the tags don't need to be in org-tag-alist for this to
> work.
>
> --
> Darlan Cavalcante Moreira
> darc...@gmail.com
>
>
> zelt...@gmail.com writes:
>
> > Thx Darlan but i cant seem to get it to work.
> > i have tried both adding ATTACH in the top of my org file:
> >
> > #+TAGS: Fav(f) todo(t) mru(m) bind(b) ATTACH(a)
> >
> > and also in my org config:
> >
> > (setq org-tag-alist '(("@work" . ?w) ("@ATTACH" . ?a) ("@dl" . ?d)
> ("@preR"
> > . ?p) ("@fav" . ?f)("@linux" . ?l)))
> >
> > and added your line to my config yet nothing happned when i add the
> ATTACH
> > tag, what am i missing here?
> >
> > best
> >
> > z
> >
> >
> >
> >
> > On Tue, Jul 23, 2013 at 2:45 PM, Darlan Cavalcante Moreira <
> > darc...@gmail.com> wrote:
> >
> >> I use the code below for the ATTACH tag
> >>
> >> --8<---cut here---start->8---
> >> (setq org-tag-faces '(("ATTACH" :inherit org-done :box nil :underline t
> >> :height 1.2)))
> >> --8<---cut here---end--->8---
> >>
> >> --
> >> Darlan Cavalcante Moreira
> >> darc...@gmail.com
> >>
> >>
> >> b...@gnu.org writes:
> >>
> >> > Hi Xebar,
> >> >
> >> > Xebar Saram writes:
> >> >
> >> >> does anyone know how (if there is a way) to style the tags with
> >> >> colors in a theme? IE to have tags with a different fg/bg from
> >> >> default and even better yet to define a different color for each
> >> >> tag?
> >> >
> >> > See this:
> >> >
> >> > C-h v org-tag-faces RET
> >> >
> >> > HTH,
> >>
>
Re: [O] Encoding Problem in export?
Am 24.07.2013 11:16, schrieb Nicolas Goaziou: Robert Eckl writes: Ok, using visible-mode i see the link with %3D, i can replace it, then all works fine. If iinsert a new link from clipboard, i get %3D. Then, as I said, `org-link-escape' (called from `org-insert-link', aka C-c C-l) is buggy. I think we should replace every occurence of `org-link-escape' with `url-encode-url' and `org-link-unescape' with `url-unhex-string'. I can't see a reason to reinvent the wheel here. AFAICT, only org-mobile.el uses optional arguments from `org-link-escape'. It just begs for a new internal function in org-mobile.el. WDYT? It's fine for me - IME you really know what you do. Thank you very much, Robert
Re: [O] Encoding Problem in export?
Nicolas Goaziou writes: > My guess is that your URL is encoded in the original buffer already. Try > to use M-x visible-mode to see what is the real URL. If you see > "http://example.de/?idprop%3D222";, it probably means that > `org-link-escape' is a bit too zealous (BTW why don't this function rely > on `url-encode-url'?) FWIW, I think this is correct: using org-insert-link runs org-link-escape with the default org-link-escape-chars which includes '='. I don't know why '=' is included, so I looked to see whether deleting it from org-link-escape-chars would cause problems. Looking at the call sites, org-link-escape is called from: o org-mobile.el but with its own set of escape chars, so that's no problem. o ob-tangle.el from org-babel-tangle-comment-links, which in turn is called (twice) from org-babel-expand-noweb-references. The default org-link-escape-chars is used, so any '=' would get escaped, but whether leaving it out would cause any problems, I don't know. o org-docview.el from org-docview-export with the default escape chars. Again, I don't know if leaving '=' out would cause any problems. o org.el from org-make-link-string (thrice) with the default escape chars and another three times from org-open-at-point, once for a "mailto" link and another two times to open an http/https/ftp/news/doi url but with a smaller set of escape chars that does not include '='. o org-make-link-string is itself called from a bunch of places: org-capture.el, org-clock.el, org.el, org-protocol.el, org-w3m.el. I didn't chase it down through these. I tried a ``git blame'' to see whether the '=' was added for some reason, but it looks as if it's been there ab initio. Maybe the thing to do is to delete '=' from org-link-escape-chars and see what problems arise. But I did find that '%' was originally in org-link-escape-chars and David Maus hardcoded it (commit 139cc1d4), so that it is *always* escaped. I assume there is a good reason for that, but if so, url-encode-url might not be enough - afaict, it leaves '%' signs alone: , | (setq url "http://www.google.org/foo=bar 30%=2") | "http://www.google.org/foo=bar 30%=2" | | (org-link-escape url) | "http://www.google.org/foo%3Dbar%2030%25%3D2"; | | (url-encode-url url) | "http://www.google.org/foo=bar%2030%=2"; ` -- Nick
Re: [O] Encoding Problem in export?
Robert Eckl writes: > Ok, using visible-mode i see the link with %3D, i can replace it, > then all works fine. If iinsert a new link from clipboard, i get %3D. Then, as I said, `org-link-escape' (called from `org-insert-link', aka C-c C-l) is buggy. I think we should replace every occurence of `org-link-escape' with `url-encode-url' and `org-link-unescape' with `url-unhex-string'. I can't see a reason to reinvent the wheel here. AFAICT, only org-mobile.el uses optional arguments from `org-link-escape'. It just begs for a new internal function in org-mobile.el. WDYT? Regards, -- Nicolas Goaziou
Re: [O] links to files in a zip archive and inline images in zip archive
John Kitchin writes: > I am trying to make an org-mode zip archive. The idea is basically to > zip up the org-file, and the images it might refer to. What I would > really like is to be able to open the zip-file in emacs, and have the > images shown inline like they are when the archive is expanded. > > I had no problem making the zip archive, and it opens fine in emacs. I > can read the org file fine, but there are no inline images, and the > links to the images do not work. > > It might be ok if the links in the org-file would open the images, but > they do not do that either (I get cannot display image: cannot > determine image type and a blank screen). > > Is this idea way off base? or is there a way to get it to work? I do > not have to stick with zip archives if another format would work well. > My guess is that your links use absolute paths. I had no problem doing this with a file using relative paths and the following directory structure: tmp -- kitchin.org `- images -- foo.png kitchin.org looks like this: --8<---cut here---start->8--- #+STARTUP: inlineimages * foo This [[file:images/foo.png]] is an inline image. --8<---cut here---end--->8--- and I zipped like this: $ zip kitchin.zip kitchin.org images I can then open the zip file, and open kitchin.org inside the zip file with the inline image showing. -- Nick
Re: [O] [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
Hi Rick, Hi Sebastien, thanks for your inputs. Well I guess Sebastien is half-right. The different settings make at least it even more tricky to see what is going on. Here is a table with the settings as I found them on my system (which I did not change) #+BEGIN_ORG | org-babel-default-header-args| ((:session . "none") (:results . "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no") (:padnewline . "yes")) | | org-babel-default-lob-header-args| ((:exports . "results")) | | org-babel-default-inline-header-args | ((:session . "none")(:results . "replace")(:exports . "results")) | #+END_ORG As you can see the most prominent cause for trouble might be :hlines As Rick should in his message it does still not solve all problems but it helps to make it more clear. I assume Eric is on holiday or otherwise busy but I guess he will find this thread and might can give us some idea, whether there was an intention in dealing with tables in that way or whether it is really considered as a bug. However, Sebastian pointed out a very important fact. Different default settings for different ways of calling a source code block. I believe that this should find its way into the manual. All the best Torsten On 22 July 2013 13:20, Torsten Wagner wrote: > Hi, > > I want to summarize the problem I found, using tables as input to source > code blocks. > This observation was shared with Rick and I would be glad to help fixing > that. > > Within the attached file one can see a typical example. > > It all comes down to a differently interpretation of tables with respect > to horizontal line. > > #+TBLNAME: with-hline > | A | B | C | > |---+---+---| > | 1 | 2 | 3 | > | X | Y | Z | > > and > > #+TBLNAME: without-hline > | A | B | C | > | 1 | 2 | 3 | > | X | Y | Z | > > will give different results being called by > > #+name: python-element > #+begin_src python :var table=with-hline :exports results > return table[1] > #+end_src > > or > > #+CALL: python-echo(with-hline) > > Please see the attached file for details. > > From what I was able to observe: > > 1. Calling a table with hline, the result of the source code block miss > the first row. Indexing is possible only for the second and third row (in > the given example) > > 2. Having no hline, the first row is available, indexing of the first row > works too. > > Using a Call construct: > 1. for a table without hline, indexing works but it does not work for a > table with hline. > 2. Interestingly, using the CALL functions, the type of both tables in > python is list for the entire table, however, indexing a table with hlines, > the type becomes NoneType whereas for a table without hline it is still of > type list. > > > Hope that can somehow help to get an idea what is going on. > > > Greetings > > Torsten > > > > > >
Re: [O] Encoding Problem in export?
Am 24.07.2013 09:34, schrieb Nicolas Goaziou: Hello, Robert Eckl writes: The issue seems to be introduced with Org-mode version 8.0.6 (release_8.0.6-4-g21dd83 org-element: Do not url-decode parsed links The description sounds like the issue, no? IIUC, this is different from your issue. You write a URL that is not encoded, and, somehow, it gets encoded in the export output. This patch is about not decoding something already encoded. You are right. My guess is that your URL is encoded in the original buffer already. Try to use M-x visible-mode to see what is the real URL. If you see "http://example.de/?idprop%3D222";, it probably means that `org-link-escape' is a bit too zealous (BTW why don't this function rely on `url-encode-url'?) Ok, using visible-mode i see the link with %3D, i can replace it, then all works fine. If iinsert a new link from clipboard, i get %3D. Regards, Robert
Re: [O] Adding support for limits and exclusions to iCal recurring events
Hello, Toke Høiland-Jørgensen writes: > Handling it in the agenda can be done by an exclusion function. I > currently have this in my org-agenda-skip-function-global (along with > another function to skip items after their END_DATE): > > (defun thj/skip-excluded () > "Skip agenda items on dates in EXCLUDE property" > (when (and (boundp 'date) date) > (let ((excluded-string (thj/get-property "EXCLUDE")) > exclusions) > (when excluded-string > (setq exclusions (mapcar > (lambda (ex-date-string) > (equal date (org-date-to-gregorian > (org-parse-time-string > ex-date-string > (split-string excluded-string ","))) > (when (memq t exclusions) > (org-end-of-subtree t)) > > (Should probably be updated to use the org native property extraction > mechanism, but this predates my discovery of that). This is a separate issue anyway: it belongs to a new thread. IMO, it's an interesting feature to be able to stop a repeated event. >> On the other hand, I'm not sure about the END_DATE property. Couldn't >> DEADLINE be used for that matter? For example, `repeater-end-date' >> could be added to `org-icalendar-use-deadline' possible values. When >> this symbol belongs to variable's value and current entry has a >> deadline, any timestamps with a repeater get deadline's value as its >> END DATE property. >> >> What do you think? > > Sure, that would work. Two possible issues spring to mind: > > 1. Is there any use cases where someone might want a deadline (in its > current use) along with an end date? Or some other conflict? I would be great to have feedback from other iCalendar users about it. > 2. Will using the DEADLINE field make it harder to add exclusion from > the agenda? (I've never really used the deadline field, so don't know > what people normally use it for). I'm clearly no Agenda specialist. I thought a DEADLINE would end a repeated event already. If it's not the case, does it make sense to implement it too? >>> +(defun org-icalendar-zero-convert-timestamp (timestamp &optional format) >>> + "Parse and format an org-formatted timestamp, zeroing the time >>> component." >>> + (let ((time (org-parse-time-string timestamp)) >>> + (fmt (or format "%Y%m%dT%H%M%SZ"))) >>> +(format-time-string fmt (encode-time 0 0 0 (nth 3 time) (nth 4 time) >>> (nth 5 time) >> >> Can't `org-icalendar-convert-timestamp' be used instead? > > It could, conceivably. However, I couldn't find any functions that would > parse a property string into the timestamp format expected by > org-icalendar-convert-timestamp, I agree it's not obvious, but: (car (org-element-parse-secondary-string "<2013-07-24 Wed>" '(timestamp))) should do the job. You can set minutes and hours to 0 in the returned object, but it's not easier than creating a new function indeed. Regards, -- Nicolas Goaziou
Re: [O] Encoding Problem in export?
Hello, Robert Eckl writes: > The issue seems to be introduced with > Org-mode version 8.0.6 (release_8.0.6-4-g21dd83 > org-element: Do not url-decode parsed links > The description sounds like the issue, no? IIUC, this is different from your issue. You write a URL that is not encoded, and, somehow, it gets encoded in the export output. This patch is about not decoding something already encoded. My guess is that your URL is encoded in the original buffer already. Try to use M-x visible-mode to see what is the real URL. If you see "http://example.de/?idprop%3D222";, it probably means that `org-link-escape' is a bit too zealous (BTW why don't this function rely on `url-encode-url'?) Regards, -- Nicolas Goaziou
Re: [O] front-matter support in version 8.0?
Hello, Vikas Rawal writes: >> > How is one expected to add front-matter for latex export in ver 8.0? >> >> You disable default table of contents and use TOC keyword (see manual) >> to put it wherever you want. E.g., >> >> #+OPTIONS: toc:nil >> >> #+BEGIN_ABSTRACT >> [Abstract here] >> #+END_ABSTRACT >> >> #+TOC: headlines > > > Thanks. This works fine. Is there a neat way to add other kind of > frontmatter (Preface, Acknowledgements etc) too? Is it different from the current example? Regards, -- Nicolas Goaziou
Re: [O] how to quote "#+end_src" string in a Babel block?
Hello, asenal writes: > My problem is How can I safely quote "#+XXX" inside a Babel-block? > I found org-mode mismatch the outter "#+begin_src" with the first > "#+end_src" inside the block hence gives me a wrong parse. > > Here's an example: > #+headers: :var varlist=top_iv > #+begin_src python :return iv_template(varlist) > def iv_template(varlist,db,table): > for var in varlist: > babel_template=''' > #+name: var > #+begin_src sqlite :db mydb > SELECT colName,cnt,suc,fal,iv FROM mytable WHERE colName == %s'; > #+end_src # org mode stop here! > ''' % (var,var) > > print babel_template > #+end_src Within a source block, you must prepend a comma to every line starting with "*" or "#+". C-c ' will do that for you. Regards, -- Nicolas Goaziou
