[O] [babel] problem with sh blocks
Hi all,
why is it, that I can not use this code in sh blocks (I get sh: 2: Bad
substitution), even though it is valid when I run the tangled
script? Is this a known thing?
#+begin_src sh :shebang "#!/bin/bash" :tangle test.sh
for i in *.org; do
echo cp "$i" "${i/%.org/.bak.org}"
done
#+end_src
How can I get the above block to execute?
Thanks in advance,
Andreas
Re: [O] [dev] Implement "ref" link types
On Feb 20, 2012, at 1:51 AM, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik writes:
>
>> Why are you saying it is not a full replacement for \ref{something}?
>
> There are still a few limitations. For example, you cannot reference
> a precise list item since items do not accept affiliated keywords.
Ah, yes, this is right.
Regards
- Carsten
>
>> It is better than that because it will work in more backends
>
> Yes, this is a big advantage.
>
>
> Regards,
>
> --
> Nicolas Goaziou
- Carsten
Re: [O] anyway to create link to a line number in a file
Not To Miss wrote: > Thanks, Nick! It works, though it works only to the specified file(s) > by overruling the original org-store-link-functions. Yes, org marches down the link handlers and takes the first positive response as the answer. You can make the function arbitrarily complicated of course, if you don't like the behavior, but in any case, it will have to say "yes" (and provide the link in some format) or "no" - in the latter case, org will continue on with the rest of the functions in the list (and fall back to its default if *no* function says "yes"). > Ideally, it would > be great if in the normal stored org link, line number could be > included in the link and would be ripped off from the text to search > the linked file. > I'm confused - what exactly are you asking for here? If you don't use the line number for searching, why would you want to store it? Nick > On Sat, Feb 18, 2012 at 4:58 PM, Nick Dokos wrote: > > Nick Dokos wrote: > > > >> Not To Miss wrote: > >> > >> > I looked that section carefully and the whole manual briefly. I > >> > haven't found anything yet. That's why I am asking on the mailing list > >> > to see if anyone has some workaround. > >> > > >> > On Sat, Feb 18, 2012 at 9:03 AM, Sean O'Halpin > >> > wrote: > >> > > On Fri, Feb 17, 2012 at 4:54 PM, Not To Miss > >> > > wrote: > >> > >> Hi all, > >> > >> > >> > >> I am reading a long text file and want to write down my notes with > >> > >> org-mode. I extremely would like to put the line numbers down along > >> > >> with my notes. Although there is a way to store a link for text search > >> > >> for the current line, I haven't found a way to create a link to a line > >> > >> number in the current buffer. Is there anyway to do that? Thanks > >> > > > >> > > Take a look at org-capture: http://orgmode.org/manual/Capture.html > >> > > > >> The problem is to make sure org-store-link will actually store the line > >> number (along with everything else) so that then org-insert-link can > >> insert the link in the proper format. I don't think there is a function > >> to do that out of the box for line numbers, but you can easily (for some > >> value of "easily") write your own. Look in > >> > >> (info "(org)Adding hyperlink types") > >> > >> for some hints. Briefly, you write a function that checks whether it > >> wants to deal with the link or not, and you add it to > >> org-store-link-functions. I don't have the time to try it out right now, > >> but I believe this should work for what you want. > >> > > > > Following up on this, the following seems to work, although you probably > > want to tweak the criterion of when you want *this* function to take > > care of links - this particular implementation only applies the line > > number treatment to links generated in the file named > > "/path/to/the.file.txt" and only that file: > > > > --8<---cut here---start->8--- > > (defun org-file-lineno-store-link() > > (when (string-equal (buffer-file-name) "/path/to/the.file.txt") > > (let* ((link (format "file:%s::%d" (buffer-file-name) > > (line-number-at-pos > > (org-store-link-props > > :type "file" > > :link link > > > > (add-hook 'org-store-link-functions 'org-file-lineno-store-link) > > --8<---cut here---end--->8--- > > > > Nick > > > > > > -- > Best, > Zhenjiang >
Re: [O] anyway to create link to a line number in a file
Thanks, Nick! It works, though it works only to the specified file(s) by overruling the original org-store-link-functions. Ideally, it would be great if in the normal stored org link, line number could be included in the link and would be ripped off from the text to search the linked file. On Sat, Feb 18, 2012 at 4:58 PM, Nick Dokos wrote: > Nick Dokos wrote: > >> Not To Miss wrote: >> >> > I looked that section carefully and the whole manual briefly. I >> > haven't found anything yet. That's why I am asking on the mailing list >> > to see if anyone has some workaround. >> > >> > On Sat, Feb 18, 2012 at 9:03 AM, Sean O'Halpin >> > wrote: >> > > On Fri, Feb 17, 2012 at 4:54 PM, Not To Miss >> > > wrote: >> > >> Hi all, >> > >> >> > >> I am reading a long text file and want to write down my notes with >> > >> org-mode. I extremely would like to put the line numbers down along >> > >> with my notes. Although there is a way to store a link for text search >> > >> for the current line, I haven't found a way to create a link to a line >> > >> number in the current buffer. Is there anyway to do that? Thanks >> > > >> > > Take a look at org-capture: http://orgmode.org/manual/Capture.html >> > >> The problem is to make sure org-store-link will actually store the line >> number (along with everything else) so that then org-insert-link can >> insert the link in the proper format. I don't think there is a function >> to do that out of the box for line numbers, but you can easily (for some >> value of "easily") write your own. Look in >> >> (info "(org)Adding hyperlink types") >> >> for some hints. Briefly, you write a function that checks whether it >> wants to deal with the link or not, and you add it to >> org-store-link-functions. I don't have the time to try it out right now, >> but I believe this should work for what you want. >> > > Following up on this, the following seems to work, although you probably > want to tweak the criterion of when you want *this* function to take > care of links - this particular implementation only applies the line > number treatment to links generated in the file named > "/path/to/the.file.txt" and only that file: > > --8<---cut here---start->8--- > (defun org-file-lineno-store-link() > (when (string-equal (buffer-file-name) "/path/to/the.file.txt") > (let* ((link (format "file:%s::%d" (buffer-file-name) > (line-number-at-pos > (org-store-link-props > :type "file" > :link link > > (add-hook 'org-store-link-functions 'org-file-lineno-store-link) > --8<---cut here---end--->8--- > > Nick > -- Best, Zhenjiang
Re: [O] Understanding org-agenda-todo-list-sublevels
On Sun, 19 Feb 2012, Bernt Hansen wrote:
lbml...@hethcote.com writes:
If I have something like:
(setq org-agenda-custom-commands
'(("Q" "Q-Who" todo "IMPLEMENT" ((org-agenda-todo-list-sublevels t)))
))
Hi Louis,
I think we need more information. In a todo agenda view you should see
the tasks and any subtasks that are not in a done state.
Your view already shows
Coding: IMPLEMENT explore percent type [33%]
Coding: IMPLEMENT the exploration
which is the task and one of the subtasks. If FINISHED is a done state
you won't get that in the view. I think PLAN should also be listed (if
it is a todo state and not a done state)
How are your todo keywords defined?
(setq org-todo-keywords (quote (
(sequence "TODO" "|" "DONE")
(sequence "SCHEDULE" "INPROCESS" "|" "COMPLETED")
(sequence "IMAGINE" "PLAN" "IMPLEMENT" "HOLD" "|" "FINISHED" "ABANDONED")
)))
(setq org-agenda-custom-commands
'(("Y" "Q-Who" todo "IMPLEMENT" ((org-agenda-todo-list-sublevels t)))
))
it occurs to me that the `todo "IMPLEMENT"` match hides the PLAN and the
"FINISHED" is out of the view by default so that it is actually
functioning as designed WRT the
*** IMPLEMENT explore percent type [33%]
todo.
Regards,
Bernt
[O] links in tables
Links with descriptions do not always display properly in tables. If I execute org-toggle-link-display, the full link text gets displayed, but table alignment is messed up. Executing org-table-align makes things look pretty again. I think it should happen automatically. Emacs : GNU Emacs 24.0.93.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-02-15 on bob.porkrind.org Package: Org-mode version 7.8.03 (release_7.8.03.421.ge7072)
Re: [O] Understanding org-agenda-todo-list-sublevels
lbml...@hethcote.com writes:
> If I have something like:
>
> (setq org-agenda-custom-commands
> '(("Q" "Q-Who" todo "IMPLEMENT" ((org-agenda-todo-list-sublevels t)))
> ))
>
> in my .emacs
>
> and I have
>
>
> *** IMPLEMENT explore slash type [1/3]
> - [X] Explore checkbox list
> - [ ] Look at the export
> - [ ] And so on
>
>
> *** IMPLEMENT explore percent type [33%]
> IMPLEMENT the exploration
> FINISHED an early step
> PLAN a third subtask
>
>
> does (org-agenda-todo-list-sublevels t) mean I should see the subtasks
> in the custom view? This doesn't seem to work for me.
>
> I get
>
> Coding: IMPLEMENT explore slash type [1/3]
>
>
> Coding: IMPLEMENT explore percent type [33%]
> Coding: IMPLEMENT the exploration
>
> alternatively,
>
> how should I set up my custom view to see the subtasks?
Hi Louis,
I think we need more information. In a todo agenda view you should see
the tasks and any subtasks that are not in a done state.
Your view already shows
> Coding: IMPLEMENT explore percent type [33%]
> Coding: IMPLEMENT the exploration
which is the task and one of the subtasks. If FINISHED is a done state
you won't get that in the view. I think PLAN should also be listed (if
it is a todo state and not a done state)
How are your todo keywords defined?
Regards,
Bernt
Re: [O] [dev] Implement "ref" link types
Hello,
Carsten Dominik writes:
> Why are you saying it is not a full replacement for \ref{something}?
There are still a few limitations. For example, you cannot reference
a precise list item since items do not accept affiliated keywords.
> It is better than that because it will work in more backends
Yes, this is a big advantage.
Regards,
--
Nicolas Goaziou
Re: [O] How to activate pre.src in org-babel html output? Can only get class=example
Hi Eric
My guess is that during export you get a message along the lines of
"htmlize is required for export". Try explicitly loading htmlize.el
(in the contrib/lisp directory of org) and then re-exporting ...
You're spot on - importing htmlize.el did the trick. However, before importing
it, there weren't any error messages about it being missing. All would work
happily, but the source block didn't have the additional src and src-python tags.
To me, this seems like a bug or at least not ideal, as the src tag and the
src- tag are related to the HTML export of #+begin_src block, not on
*how* the HTML is styled (i.e. by the user or htmlize).
For those searching the mailing list later:
; For pretty-printed formatted source code on HTML export,
; load htmlize.el in init.el or the emacs config file
(load-file "~/.emacs.d/orgmode/contrib/lisp/htmlize.el")
I've got the orgmode source in the .emacs.d directory so I can pull updates
using git, otherwise look for contrib/lisp/htmlize.el in the main Emacs directory.
With htmlize.el loaded, exporting:
,
| #+begin_src python :results output :exports both
| print "Pi = ", 355/113.0
| #+end_src python
`
Results in the src block having the src and src-python CSS tags:
,
|
|print
|"Pi =", 355/113.0
|
|
|
|
| Pi = 3.14159292035
|
`
with an automatically added little "Python" flag box on the Python src block.
Some custom CSS can be used to make the src and output a little more distinct. A
simple way is it place these lines at the top of the file:
#+style: pre.src {background-color: #DD;}
#+style: .example {background-color: #CC;}
However, you have to be consistent about using #+begin_src blocks rather than
just a colon or using begin_example at the beginning of lines for src fragments
that don't output anything, otherwise Python src they'll come out with the
output colouring. The keyboard shortcut (< s tab) for getting a
#+begin_src---#+end_src block is handy here.
Although the example above relates to #+begin_src python blocks, the fix should
work with other languages.
Cheers and thanks
Giovanni
==
Dr Giovanni Moretti | School of Engineering and Advanced Technology
Senior Lecturer | Massey University, Palmerston North, New Zealand
Computer Science| Ph +64-6-3505799x2474 Fax +64-6-3502259 - ZL2GX
==
http://seat.massey.ac.nz/morettig.more...@massey.ac.nz
Re: [O] Temp files from testing are permanent...
FTR, I'm just commenting based on experience with a testing harness for a completely unrelated piece of software. Achim Gratz writes: > Eric Schulte writes: >> I should have been more clear. I'm thinking that this would be a macro >> used /within/ unit tests so that testers could specify what files will >> be created (test writers should be able to predict the file names >> created by their tests) and then the macro will handle cleanup. Test writers can predict/choose the file names created by their tests but they cannot predict the file names creates by other test writers' tests (or their own tests written two weeks ago ;-). Unless there is some naming policy that is strictly adhered to, the chance of collisions remains. One approach that has worked for me is to have tests create their outputs in a directory named after the test. So if I have a test implemented in test.el, it would create all outputs in test.out/, for example. As I put all my tests and their inputs in a tests/ directory (and nothing else), I can just `rm -rf *.out` there to clean up. > I'm sitting on the fence with this. Running the tests from the Makefile > it would probably be more difficult to ensure that one could keep the > files when the tests were trying to clean up after themselves (as some > option would need to be injected into the test invocation and/or a > different test command would need to be called). Personally, I prefer to have `make clean` take care of cleaning up my test outputs. I control when it gets run, can move valuable stuff out of the way before doing so and none of the tests have to bother with conditionalized clean up. >> I do like the idea of a single directory in which all output files may >> be collected. The only potential downside I see for this is that files >> will be generated both from within org files in the testing/examples >> directory as well as temporary files. > > The temporary files could be in a sub-directory... or each test (group) > could have their own sub-directory. Whatever the organisation, there > should be a single directory which, if recursively removed, gets rid of > all files created by the test run. See above. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[O] Understanding org-agenda-todo-list-sublevels
If I have something like:
(setq org-agenda-custom-commands
'(("Q" "Q-Who" todo "IMPLEMENT" ((org-agenda-todo-list-sublevels t)))
))
in my .emacs
and I have
*** IMPLEMENT explore slash type [1/3]
- [X] Explore checkbox list
- [ ] Look at the export
- [ ] And so on
*** IMPLEMENT explore percent type [33%]
IMPLEMENT the exploration
FINISHED an early step
PLAN a third subtask
does (org-agenda-todo-list-sublevels t) mean I should see the subtasks in
the custom view? This doesn't seem to work for me.
I get
Coding: IMPLEMENT explore slash type [1/3]
Coding: IMPLEMENT explore percent type [33%]
Coding: IMPLEMENT the exploration
alternatively,
how should I set up my custom view to see the subtasks?
Thanks for any assistance,
Louis
Re: [O] Displaying or linking to definitions of terms?
Nicolas Goaziou writes: > Hello, > > There are probably a lot of ways to achieve this with included tools. > For example, on a per file basis, you may use radio targets: > > #+begin_src org > Contempt for happiness is usually contempt for other people's happiness, > and is an elegant hatred for the human race. > > * Definitions > > - <<>> :: pleasingly graceful and stylish in appearance or > manner; pleasingly ingenious and simple. > #+end_src > > Note that you have to activate <<>> radio target the first time > you introduce it (with C-c C-c), but present and future radio targets > will be liked to it automatically. > > > Regards, Thanks, I had somehow totally forgot about the '<<>>' targets, they'll probably serve my purposes for the time being.
Re: [O] [0][babel][R] Undesired conversion of integers to floats in R code block output
Eric Schulte writes: >> >> A further followup, at the risk of descending into minutia. The >> culprit seems to be the emacs function string-to-number. >> >> On my 32-bit Arch machine: >> (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) >> (string-to-number "987654321"): 987654321.0 Since that latter number is not representable as an integer in Emacs (it loses 4 bit due to the way Lisp represents these things), it takes the next best thing (FP in that case). Since you are on Arch, I believe there is a way to compile Emacs to use "large integers" even on 32bit systems - it may have other problems, but should solve this. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] [0][babel][R] Undesired conversion of integers to floats in R code block output
On Sun 19 Feb 2012 12:46:15 PM PST, Eric Schulte wrote: A further followup, at the risk of descending into minutia. The culprit seems to be the emacs function string-to-number. On my 32-bit Arch machine: (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) (string-to-number "987654321"): 987654321.0 GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-02-01 on shirley.hoetzel.info On a 64-bit Ubuntu (11.10) machine: (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) (string-to-number "987654321"): 987654321 (#o7267464261, #x3ade68b1) GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.5) of 2011-08-14 on allspice, modified by Debian Ah, nice debugging! That must be the issue, as I'm working on a 64-bit machine. Maybe one workaround could be to prefix the numbers with a letter in R-land so that emacs interprets them as strings. Cheers, Poking around the web I found that emacs guarantees 28 bits as a minimum precision. For a while I did as you suggested, prefixing all subjects ids with 'id'. But it's cleaner if I reinstall a 64-bit version of Arch. From your experiments, I already know its 64-bit version of emacs supports at least 30 bits. Thanks again for your help. Dan
Re: [O] [dev] Implement "ref" link types
On 2012-02-19, Nicolas Goaziou wrote: > Ok, I found the thread[1] about extensible syntax for links. Again this isn't just for links and if your syntax does all you ever anticipate, then I like it. I am talking about the future and the difficulty of adding ad-hoc syntax fore new features /later/. There are a few other threads (just FYI). I might have them listed someplace. Overview (also FYI): one concern is syntax creep in Org for new features. This affects external parsers and overall complexity and nonorthogonality, and introduces parsing risk, in which there are many gotchas -- such as inability to escape, quote, nest, pretty-print, etc. ES/US solves all of that in a single, simple way. If all you're doing is the one set of features now, then your syntax is great. But I'm talking about the future. > I don't think that it would be a good idea to use a completely different > syntax for just one type of link. Either we change the whole link system No, it's not for just one type of link. It applies to new features also, not just for ref links but for ID markers (links to anything, even words, using Org ID), very fancy dates that have features that are too difficult to include in existing date syntax, annotation of words or paragraphs or elements, maybe fancy detangling, browser-like link coloring by expiry and cached links, digraphs, undirected graphs including bidirectional links, super-fancy footnotes, any new feature we do not currently anticipate for the ref syntax or any other feature that would create nonorthogonality and complexity in existing syntax, and many new features we haven't thought of. It won't replace existing syntax. It's for new features. One point is that when we address something (such as nestability) for one new feature, it works for all others automatically. > into the extensible syntax proposal, or we don't change it at > all. I don't mind either way, but that's orthogonal to the problem at > hand. Again I think your syntax is great if that is all it is going to do. All I am doing is raising a possible alternative way of doing it. If you don't like it, that's fine. But my point is that if we only look at the problem at hand, we get syntax creep -- because new features are not at hand. Think of how dates now have to deal with deadlines, repeaters, etc. That's OK, but it's going to get harder to add new features to them. I'm not saying to replace dates, but for many new features, we might want to try something more orthogonal and extensible and universal. >> For example, you might want to put the target anywhere, not just where >> there are elements. > > Org already has targets for that: <> and [[anywhere]]. The Those do not use the Org ID mechanism, so they are brittle and don't operate across files in the same way Org IDs can (IIRC -- do they?). Again it's an example of how the syntax can add features without making parsing difficult. This all concerns future features, not anything today. Just something to consider. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] [0][babel][R] Undesired conversion of integers to floats in R code block output
> > A further followup, at the risk of descending into minutia. The > culprit seems to be the emacs function string-to-number. > > On my 32-bit Arch machine: > (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) > (string-to-number "987654321"): 987654321.0 > GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of > 2012-02-01 on shirley.hoetzel.info > > On a 64-bit Ubuntu (11.10) machine: > (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) > (string-to-number "987654321"): 987654321 (#o7267464261, #x3ade68b1) > GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.5) of > 2011-08-14 on allspice, modified by Debian > Ah, nice debugging! That must be the issue, as I'm working on a 64-bit machine. Maybe one workaround could be to prefix the numbers with a letter in R-land so that emacs interprets them as strings. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [dev] Implement "ref" link types
On 2/19/12 8:41 PM, Nicolas Goaziou wrote: That's another possibility, but I'd rather follow LaTeX usage. I think it gives user more latitude in the end. Indeed, You don't have to think about a name prefix ; you can also have constructs like "Tables [[ref:table1]], [[ref:table2]] and [[ref:table3]]" for "Tables 1, 2 and 3", etc. Good points. Note that the behaviour you suggest can easily be implemented using filters in the new exporter. Right. I regret not having had the time to play with the new exporter and give feedback, it sounds very smart. Christian
Re: [O] [dev] Implement "ref" link types
On Sun, Feb 19, 2012 at 08:41:45PM +0100, Nicolas Goaziou wrote:
> > Suggestion: On export, how about enabling automatic element
> > descriptions for references following the type:name convention, so
> > that e.g. just
> >
> > : in [[ref:tab:numbers]] we can see...
> >
> > would expand to
> >
> > in Table 2 we can see...
> >
> > If implemented, this should be user-customizable e.g. through an alist
> > like
> >
> > (("fig" . "Figure") ("tab" . "Table") ("map" . "Map"))
>
> That's another possibility, but I'd rather follow LaTeX usage. I think
> it gives user more latitude in the end. Indeed, You don't have to think
> about a name prefix ; you can also have constructs like "Tables
> [[ref:table1]], [[ref:table2]] and [[ref:table3]]" for "Tables 1, 2 and
> 3", etc.
>
> Note that the behaviour you suggest can easily be implemented using
> filters in the new exporter.
Note that for LaTeX export, there's no need to explicitly add names to
references -- LaTeX can figure them out for itself from the label alone,
with a little of help.
There are various CTAN packages implementing this, such as cleveref,
hyperref's \autoref command, varioref's \labelformat command... Cleveref
is arguably the most powerful of these, as you can just chuck references
into a \cref command (which replaces \ref):
\cref{figure1,table1,table3,table2}, and it sorts them all out for you,
to produce "Figure~1, and Tables~1 to~3". (Disclaimer: I'm the author of
cleveref.)
Toby
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: ts...@cantab.net
web: www.dr-qubit.org
Re: [O] [dev] Implement "ref" link types
On 19.2.2012, at 19:08, Nicolas Goaziou wrote:
> Hello,
>
> I'd like to introduce a new type of internal links, namely "ref" links.
>
> Since any element can now have a "#+name: something" affiliated keyword,
> it would be practical to have a way to go straight to that name, from
> anywhere in the buffer. The following patch implements
> a [[ref:something]] syntax, or even [[ref:something][text]] to do so.
>
> The problem that I see here is that is breaks a bit syntax for internal
> links ("protocol:path" is usually for external links). Another solution
> would be to make them more hermetic: [[!something]].
>
> On the export side, a "ref" link should be replaced by its description,
> if it has any, or by the sequence number of the matching element among
> elements of the same type. With the new exporter and the following
> buffer:
>
> #+begin_src org
> #+name: tab:letters
> #+caption: Letters
> | a | b |
> | c | d |
>
> #+name: tab:numbers
> #+caption: Numbers
> | 1 |
> | 2 |
>
>
> In tableau [[ref:tab:numbers]] we can see... Yet, in
> [[ref:tab:numbers][the same table]], ...
> #+end_src
>
> the last sentence, in ascii, becomes:
>
> In tableau 2 we can see... Yet, in the same table, ...
>
>
> Even if it's not a perfect replacement for "\ref{something}" commands,
> it should be sufficient for all major back-ends to provide an
> approximate functionality. And we gain interactivity in the Org buffer.
>
> What do you think?
Love it! Why are you saying it is not a full replacement for \ref{something}?
It is better than that because it will work in more backends
- Carsten
>
>
> Regards,
>
> --
> Nicolas Goaziou
> From f92e12a9482613d4b1d27090fac8d2667b094fdb Mon Sep 17 00:00:00 2001
> From: Nicolas Goaziou
> Date: Sun, 19 Feb 2012 18:48:41 +0100
> Subject: [PATCH] Implement "ref" internal link type in Org buffers
>
> * lisp/org.el (org-link-search): Handle "ref" internal link types.
>
> A [[ref:some-name]] link points to a "#+name: some-name" in the same
> buffer.
> ---
> lisp/org.el | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index a81f7fc..ea06863 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -9875,6 +9875,16 @@ visibility around point, thus ignoring
> ;; First check if there are any special search functions
> ((run-hook-with-args-until-success 'org-execute-file-search-functions s))
> ;; Now try the builtin stuff
> + ;; Ref internal link.
> + ((and (string-match "^ref:\\(.*\\)" s0)
> +(let ((name (org-trim (match-string 1 s0
> + (save-excursion
> +(goto-char (point-min))
> +(and (re-search-forward
> + (format "^[ \t]*#\\+name: %s" name) nil t)
> + (setq type 'dedicated pos (match-beginning 0))
> + (goto-char pos))
> + ;; Custom-id
> ((and (equal (string-to-char s0) ?#)
> (> (length s0) 1)
> (save-excursion
> --
> 1.7.9.1
>
Re: [O] [dev] Implement "ref" link types
Hello, Samuel Wales writes: > I think it's a good idea, and would suggest this: > > * If it is not going to have features added, then [[ref:asdf]] is OK > * If it /is/ going to have features added, then I recommend ES/US > > ES/US is extensible syntax / universal syntax, a specific proposal for > an orthogonal and future-proof syntax for new capabilities like this. Ok, I found the thread[1] about extensible syntax for links. I don't think that it would be a good idea to use a completely different syntax for just one type of link. Either we change the whole link system into the extensible syntax proposal, or we don't change it at all. I don't mind either way, but that's orthogonal to the problem at hand. For now, I'll assume we keep the classical link syntax. > For example, you might want to put the target anywhere, not just where > there are elements. Org already has targets for that: <> and [[anywhere]]. The [[ref:element]] link is more interesting for its export effect. Moving back and forth between it and targeted element is a bonus. Regards, [1] http://thread.gmane.org/gmane.emacs.orgmode/11896 -- Nicolas Goaziou
Re: [O] [dev] Implement "ref" link types
Hello,
Christian Moe writes:
> Me, I don't see any problem with a [[ref:something]] syntax. It's the
> obvious org-native, cross-backend replacement for \ref. The
> [[protocol:something]] syntax already widens the notion of link to
> shell: and elisp: links, so I wouldn't worry about breaking
> conventions. Using e.g. [[!something]] instead would introduce a brand
> new bit of syntax.
Not really brand new, since there already are [[#custom-id]] and
[[*headline]]. Though, I'd favour [[ref:name]], too.
> Suggestion: On export, how about enabling automatic element
> descriptions for references following the type:name convention, so
> that e.g. just
>
> : in [[ref:tab:numbers]] we can see...
>
> would expand to
>
> in Table 2 we can see...
>
> If implemented, this should be user-customizable e.g. through an alist
> like
>
> (("fig" . "Figure") ("tab" . "Table") ("map" . "Map"))
That's another possibility, but I'd rather follow LaTeX usage. I think
it gives user more latitude in the end. Indeed, You don't have to think
about a name prefix ; you can also have constructs like "Tables
[[ref:table1]], [[ref:table2]] and [[ref:table3]]" for "Tables 1, 2 and
3", etc.
Note that the behaviour you suggest can easily be implemented using
filters in the new exporter.
Regards,
--
Nicolas Goaziou
Re: [O] [dev] Implement "ref" link types
I think it's a good idea, and would suggest this: * If it is not going to have features added, then [[ref:asdf]] is OK * If it /is/ going to have features added, then I recommend ES/US ES/US is extensible syntax / universal syntax, a specific proposal for an orthogonal and future-proof syntax for new capabilities like this. For example, you might want to put the target anywhere, not just where there are elements. The ID marker idea implements this with ES/US. In this case, we'd simply allow element names in addition with the same source syntax. Of course, you might decide that nobody will ever want to add new syntax to those links, in which case a simple new link type would make sense. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] [dev] Implement "ref" link types
Hi,
I think it's a great idea, as I've wanted to do it myself :-) , but
I'm glad it's in competent hands instead.
Me, I don't see any problem with a [[ref:something]] syntax. It's the
obvious org-native, cross-backend replacement for \ref. The
[[protocol:something]] syntax already widens the notion of link to
shell: and elisp: links, so I wouldn't worry about breaking
conventions. Using e.g. [[!something]] instead would introduce a brand
new bit of syntax.
Suggestion: On export, how about enabling automatic element
descriptions for references following the type:name convention, so
that e.g. just
: in [[ref:tab:numbers]] we can see...
would expand to
in Table 2 we can see...
If implemented, this should be user-customizable e.g. through an alist
like
(("fig" . "Figure") ("tab" . "Table") ("map" . "Map"))
Yours,
Christian
On 2/19/12 7:08 PM, Nicolas Goaziou wrote:
Hello,
I'd like to introduce a new type of internal links, namely "ref" links.
Since any element can now have a "#+name: something" affiliated keyword,
it would be practical to have a way to go straight to that name, from
anywhere in the buffer. The following patch implements
a [[ref:something]] syntax, or even [[ref:something][text]] to do so.
The problem that I see here is that is breaks a bit syntax for internal
links ("protocol:path" is usually for external links). Another solution
would be to make them more hermetic: [[!something]].
On the export side, a "ref" link should be replaced by its description,
if it has any, or by the sequence number of the matching element among
elements of the same type. With the new exporter and the following
buffer:
#+begin_src org
#+name: tab:letters
#+caption: Letters
| a | b |
| c | d |
#+name: tab:numbers
#+caption: Numbers
| 1 |
| 2 |
In tableau [[ref:tab:numbers]] we can see... Yet, in
[[ref:tab:numbers][the same table]], ...
#+end_src
the last sentence, in ascii, becomes:
In tableau 2 we can see... Yet, in the same table, ...
Even if it's not a perfect replacement for "\ref{something}" commands,
it should be sufficient for all major back-ends to provide an
approximate functionality. And we gain interactivity in the Org buffer.
What do you think?
Regards,
Re: [O] [0][babel][R] Undesired conversion of integers to floats in R code block output
On 02/19/2012 10:28 AM, Daniel Drake wrote: On 02/19/2012 09:40 AM, Daniel Drake wrote: On 02/19/2012 08:48 AM, Eric Schulte wrote: Just to be safe, I nuked my org-mode directory and re-cloned from the git repository: I'm now at release_7.8.03.386.g2239d (I was at release_7.8.03-351-g47eb3 previously). Is there a more recent version? I also removed the org directory that came with the packaged version of emacs, just in case. This sounds just like my setup. I get the following from `org-version' which should be equivalent. Org-mode version 7.8.03 (release_7.8.03.419.gdeb6e) I start emacs with the following options: $ emacs -Q -eval '(setq load-path (cons "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require ob-R)" test.org I just did the same using the following command line to launch Emacs, and I still get no decimal place in my results. $ emacs -Q -eval '(setq laod-path (cons "~/.emacs.d/src/org/lisp/" load-path))' -eval "(require 'ob-R)" /tmp/dan.org I get the same behavior as before. I was a little puzzled when I saw this happen, as I've been working on this study for over a year in org and it's the first time I've seen this behavior. I went back and tried previous versions (e.g., 7.4), and now I see the same thing. I wonder if Arch (a rolling release linux distribution that tries to be close to the leading edge) has updated an underlying library that impacts the babel code in some odd way. (Granted, I don't see how this could be, as the emacs environment seems pretty well insulated from the underlying OS; PEBKAC just as likely.) I doubt this is the case. I also use Arch (just ran pacman -Syu this morning) so we likely have the largely same underlying versions of libraries installed. Maybe the issue could lay somewhere in your R config? Sorry I can't be of more help. Best, At first I thought it was R as well, but the fact that there is no decimal point in the output file plus the fact that (outside of emacs) I can use read.table to pull in the table and the result has no decimal formatting makes me think otherwise. That you're running the same setup as me, though, gives me hope. I can backup, re-install Arch, and see if the problem goes away. Thanks for your help. I'm not certain when I'll have time to try this, but I'll follow up on this thread when I do. Best, Dan I'm following up on my last post, just to have it in the record: I've boiled down the behavior to these two examples: output the results by value vs output. R seems not to have anything to do with it. Somehow the "by value" code is intervening. I'll try to debug. command line: $ emacs -Q -eval '(setq load-path (cons "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require 'ob-sh)" test.org In the buffer: *** by output #+name: by-output #+begin_src sh :results output echo 987654321 #+end_src #+RESULTS: by-output : 987654321 *** by value #+name: by-value #+begin_src sh :results value echo 987654321 #+end_src #+RESULTS: by-value : 987654321.0 A further followup, at the risk of descending into minutia. The culprit seems to be the emacs function string-to-number. On my 32-bit Arch machine: (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) (string-to-number "987654321"): 987654321.0 GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-02-01 on shirley.hoetzel.info On a 64-bit Ubuntu (11.10) machine: (string-to-number "123456789"): 123456789 (#o726746425, #x75bcd15) (string-to-number "987654321"): 987654321 (#o7267464261, #x3ade68b1) GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.5) of 2011-08-14 on allspice, modified by Debian The extra 3 bits required to represent the larger number apparently push my version of emacs into floating point territory.(log2(987654321)=29.87943; log2(123456789)=26.87943) Don't know if the difference is between emacs versions or 32- vs. 64-bit implementations, but I can probably figure it out from here. In any event, this doesn't seem to be an org-mode problem. Thanks again for all your help and for org-mode/babel in general! Dan In any event, since you can't reproduce the behavior (thanks again for trying), I don't expect it's anything you can fix. Maybe it will show up in other distributions as they update to more current versions. In the mean time, I'll try to improve my elisp skills and figure out where the extraneous formatting occurs. Best, Dan - GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-02-01 on shirley.hoetzel.info - Org-mode version 7.8.03 (release_7.8.03.386.g2239d)
Re: [O] [0][babel][R] Undesired conversion of integers to floats in R code block output
On 02/19/2012 09:40 AM, Daniel Drake wrote: On 02/19/2012 08:48 AM, Eric Schulte wrote: Just to be safe, I nuked my org-mode directory and re-cloned from the git repository: I'm now at release_7.8.03.386.g2239d (I was at release_7.8.03-351-g47eb3 previously). Is there a more recent version? I also removed the org directory that came with the packaged version of emacs, just in case. This sounds just like my setup. I get the following from `org-version' which should be equivalent. Org-mode version 7.8.03 (release_7.8.03.419.gdeb6e) I start emacs with the following options: $ emacs -Q -eval '(setq load-path (cons "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require ob-R)" test.org I just did the same using the following command line to launch Emacs, and I still get no decimal place in my results. $ emacs -Q -eval '(setq laod-path (cons "~/.emacs.d/src/org/lisp/" load-path))' -eval "(require 'ob-R)" /tmp/dan.org I get the same behavior as before. I was a little puzzled when I saw this happen, as I've been working on this study for over a year in org and it's the first time I've seen this behavior. I went back and tried previous versions (e.g., 7.4), and now I see the same thing. I wonder if Arch (a rolling release linux distribution that tries to be close to the leading edge) has updated an underlying library that impacts the babel code in some odd way. (Granted, I don't see how this could be, as the emacs environment seems pretty well insulated from the underlying OS; PEBKAC just as likely.) I doubt this is the case. I also use Arch (just ran pacman -Syu this morning) so we likely have the largely same underlying versions of libraries installed. Maybe the issue could lay somewhere in your R config? Sorry I can't be of more help. Best, At first I thought it was R as well, but the fact that there is no decimal point in the output file plus the fact that (outside of emacs) I can use read.table to pull in the table and the result has no decimal formatting makes me think otherwise. That you're running the same setup as me, though, gives me hope. I can backup, re-install Arch, and see if the problem goes away. Thanks for your help. I'm not certain when I'll have time to try this, but I'll follow up on this thread when I do. Best, Dan I'm following up on my last post, just to have it in the record: I've boiled down the behavior to these two examples: output the results by value vs output. R seems not to have anything to do with it. Somehow the "by value" code is intervening. I'll try to debug. command line: $ emacs -Q -eval '(setq load-path (cons "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require 'ob-sh)" test.org In the buffer: *** by output #+name: by-output #+begin_src sh :results output echo 987654321 #+end_src #+RESULTS: by-output : 987654321 *** by value #+name: by-value #+begin_src sh :results value echo 987654321 #+end_src #+RESULTS: by-value : 987654321.0 In any event, since you can't reproduce the behavior (thanks again for trying), I don't expect it's anything you can fix. Maybe it will show up in other distributions as they update to more current versions. In the mean time, I'll try to improve my elisp skills and figure out where the extraneous formatting occurs. Best, Dan - GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-02-01 on shirley.hoetzel.info - Org-mode version 7.8.03 (release_7.8.03.386.g2239d)
[O] [dev] Implement "ref" link types
Hello,
I'd like to introduce a new type of internal links, namely "ref" links.
Since any element can now have a "#+name: something" affiliated keyword,
it would be practical to have a way to go straight to that name, from
anywhere in the buffer. The following patch implements
a [[ref:something]] syntax, or even [[ref:something][text]] to do so.
The problem that I see here is that is breaks a bit syntax for internal
links ("protocol:path" is usually for external links). Another solution
would be to make them more hermetic: [[!something]].
On the export side, a "ref" link should be replaced by its description,
if it has any, or by the sequence number of the matching element among
elements of the same type. With the new exporter and the following
buffer:
#+begin_src org
#+name: tab:letters
#+caption: Letters
| a | b |
| c | d |
#+name: tab:numbers
#+caption: Numbers
| 1 |
| 2 |
In tableau [[ref:tab:numbers]] we can see... Yet, in
[[ref:tab:numbers][the same table]], ...
#+end_src
the last sentence, in ascii, becomes:
In tableau 2 we can see... Yet, in the same table, ...
Even if it's not a perfect replacement for "\ref{something}" commands,
it should be sufficient for all major back-ends to provide an
approximate functionality. And we gain interactivity in the Org buffer.
What do you think?
Regards,
--
Nicolas Goaziou
>From f92e12a9482613d4b1d27090fac8d2667b094fdb Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Sun, 19 Feb 2012 18:48:41 +0100
Subject: [PATCH] Implement "ref" internal link type in Org buffers
* lisp/org.el (org-link-search): Handle "ref" internal link types.
A [[ref:some-name]] link points to a "#+name: some-name" in the same
buffer.
---
lisp/org.el | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index a81f7fc..ea06863 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9875,6 +9875,16 @@ visibility around point, thus ignoring
;; First check if there are any special search functions
((run-hook-with-args-until-success 'org-execute-file-search-functions s))
;; Now try the builtin stuff
+ ;; Ref internal link.
+ ((and (string-match "^ref:\\(.*\\)" s0)
+ (let ((name (org-trim (match-string 1 s0
+ (save-excursion
+ (goto-char (point-min))
+ (and (re-search-forward
+ (format "^[ \t]*#\\+name: %s" name) nil t)
+ (setq type 'dedicated pos (match-beginning 0))
+ (goto-char pos))
+ ;; Custom-id
((and (equal (string-to-char s0) ?#)
(> (length s0) 1)
(save-excursion
--
1.7.9.1
Re: [O] [0][babel][R] Undesired conversion of integers to floats in R code block output
On 02/19/2012 08:48 AM, Eric Schulte wrote: Just to be safe, I nuked my org-mode directory and re-cloned from the git repository: I'm now at release_7.8.03.386.g2239d (I was at release_7.8.03-351-g47eb3 previously). Is there a more recent version? I also removed the org directory that came with the packaged version of emacs, just in case. This sounds just like my setup. I get the following from `org-version' which should be equivalent. Org-mode version 7.8.03 (release_7.8.03.419.gdeb6e) I start emacs with the following options: $ emacs -Q -eval '(setq load-path (cons "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require ob-R)" test.org I just did the same using the following command line to launch Emacs, and I still get no decimal place in my results. $ emacs -Q -eval '(setq laod-path (cons "~/.emacs.d/src/org/lisp/" load-path))' -eval "(require 'ob-R)" /tmp/dan.org I get the same behavior as before. I was a little puzzled when I saw this happen, as I've been working on this study for over a year in org and it's the first time I've seen this behavior. I went back and tried previous versions (e.g., 7.4), and now I see the same thing. I wonder if Arch (a rolling release linux distribution that tries to be close to the leading edge) has updated an underlying library that impacts the babel code in some odd way. (Granted, I don't see how this could be, as the emacs environment seems pretty well insulated from the underlying OS; PEBKAC just as likely.) I doubt this is the case. I also use Arch (just ran pacman -Syu this morning) so we likely have the largely same underlying versions of libraries installed. Maybe the issue could lay somewhere in your R config? Sorry I can't be of more help. Best, At first I thought it was R as well, but the fact that there is no decimal point in the output file plus the fact that (outside of emacs) I can use read.table to pull in the table and the result has no decimal formatting makes me think otherwise. That you're running the same setup as me, though, gives me hope. I can backup, re-install Arch, and see if the problem goes away. Thanks for your help. I'm not certain when I'll have time to try this, but I'll follow up on this thread when I do. Best, Dan In any event, since you can't reproduce the behavior (thanks again for trying), I don't expect it's anything you can fix. Maybe it will show up in other distributions as they update to more current versions. In the mean time, I'll try to improve my elisp skills and figure out where the extraneous formatting occurs. Best, Dan - GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-02-01 on shirley.hoetzel.info - Org-mode version 7.8.03 (release_7.8.03.386.g2239d)
Re: [O] Temp files from testing are permanent...
Eric Schulte writes: > I should have been more clear. I'm thinking that this would be a macro > used /within/ unit tests so that testers could specify what files will > be created (test writers should be able to predict the file names > created by their tests) and then the macro will handle cleanup. I'm sitting on the fence with this. Running the tests from the Makefile it would probably be more difficult to ensure that one could keep the files when the tests were trying to clean up after themselves (as some option would need to be injected into the test invocation and/or a different test command would need to be called). > I do like the idea of a single directory in which all output files may > be collected. The only potential downside I see for this is that files > will be generated both from within org files in the testing/examples > directory as well as temporary files. The temporary files could be in a sub-directory... or each test (group) could have their own sub-directory. Whatever the organisation, there should be a single directory which, if recursively removed, gets rid of all files created by the test run. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] [0][babel][R] Undesired conversion of integers to floats in R code block output
> Just to be safe, I nuked my org-mode directory and re-cloned from the > git repository: I'm now at release_7.8.03.386.g2239d (I was at > release_7.8.03-351-g47eb3 previously). Is there a more recent > version? I also removed the org directory that came with the packaged > version of emacs, just in case. > This sounds just like my setup. I get the following from `org-version' which should be equivalent. Org-mode version 7.8.03 (release_7.8.03.419.gdeb6e) > > I start emacs with the following options: > $ emacs -Q -eval '(setq load-path (cons > "~/share/emacs/site-lisp/org-mode/lisp" load-path))' -eval "(require > ob-R)" test.org > I just did the same using the following command line to launch Emacs, and I still get no decimal place in my results. $ emacs -Q -eval '(setq laod-path (cons "~/.emacs.d/src/org/lisp/" load-path))' -eval "(require 'ob-R)" /tmp/dan.org > > I get the same behavior as before. I was a little puzzled when I saw > this happen, as I've been working on this study for over a year in org > and it's the first time I've seen this behavior. I went back and > tried previous versions (e.g., 7.4), and now I see the same thing. > > I wonder if Arch (a rolling release linux distribution that tries to > be close to the leading edge) has updated an underlying library that > impacts the babel code in some odd way. (Granted, I don't see how > this could be, as the emacs environment seems pretty well insulated > from the underlying OS; PEBKAC just as likely.) > I doubt this is the case. I also use Arch (just ran pacman -Syu this morning) so we likely have the largely same underlying versions of libraries installed. Maybe the issue could lay somewhere in your R config? Sorry I can't be of more help. Best, > > In any event, since you can't reproduce the behavior (thanks again for > trying), I don't expect it's anything you can fix. Maybe it will show > up in other distributions as they update to more current versions. In > the mean time, I'll try to improve my elisp skills and figure out > where the extraneous formatting occurs. > > Best, > Dan > > - GNU Emacs 23.4.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of > 2012-02-01 on shirley.hoetzel.info > - Org-mode version 7.8.03 (release_7.8.03.386.g2239d) > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Temp files from testing are permanent...
Achim Gratz writes:
> Eric Schulte writes:
>> It will be up to the authors of individual tests to remove tangled and
>> exported files. Ideally we can patch each test to clean up after
>> itself. Perhaps we should provide a test macro which accepts a list of
>> file names and optionally removes them if the test exists successfully.
>> e.g.,
>>
>> (org-test-with-cleanup '("exported.html" "tangled.sh" etc...)
>> ...test body...)
>
> Currently those files would have inpredictable names AFAICS, which would
> defeat that purpose.
I should have been more clear. I'm thinking that this would be a macro
used /within/ unit tests so that testers could specify what files will
be created (test writers should be able to predict the file names
created by their tests) and then the macro will handle cleanup. Here's
one implementation of such a macro
(defmacro org-test-with-cleanup (files &rest body)
"If BODY executes successfully delete FILES and return results of BODY."
(declare (indent 1))
`(let ((result (progn ,@body)))
(mapc (lambda (file) (when (file-exists-p file) (delete-file file)))
files)
result))
> I'm not sure where to do this, but it occurs to me that it would be
> easier if those files only had a unique prefix that didn't change for
> each invocation of the test suite (a timestamp would be OK, so it is
> easier to see which files you're looking at). If the files always had
> the same name, you would have to make sure that there was no
> collision, either with existing files or results from earlier tests,
> so that would be no good. If it is easier to always have the same
> names for the files, one could just make the test directory name
> unique. I think it is useful for debugging to be able to keep a few
> generation of tests around.
>
I do like the idea of a single directory in which all output files may
be collected. The only potential downside I see for this is that files
will be generated both from within org files in the testing/examples
directory as well as temporary files.
>
>> Even if the above is implemented this sounds like a good safeguard.
>
> Safeguards are in place in my Makefile fork.
>
>
> Regards,
> Achim.
--
Eric Schulte
http://cs.unm.edu/~eschulte/
[O] patch for warning time (first baby sted)
Hi,
This patch implements warn time for org appt. It only works on emacs bzr
(the variable appt-warning-time-regexp appears in it). You need to add
the warntime in the text of the entry, like so :
* doctor warntime 10
<2012-02-19 10:00>
or
* doctor warntime 10 <2012-02-19 10:00>
The patch is not fit to be included in org. I am submitting it in case
it interests others to have the functionality.
diff --git a/emacs/org/org-agenda.el b/emacs/org/org-agenda.el
index 780794e..78194b1 100644
--- a/emacs/org/org-agenda.el
+++ b/emacs/org/org-agenda.el
@@ -8518,6 +8518,11 @@ details and examples."
(let* ((evt (org-trim (or (get-text-property 1 'txt x) "")))
(cat (get-text-property 1 'org-category x))
(tod (get-text-property 1 'time-of-day x))
+ (warn-match (string-match appt-warning-time-regexp evt))
+ (warntime
+ (when warn-match
+ (string-to-number (match-string 1 evt))
+ (setq evt (substring literal 0 warn-match
(ok (or (null filter)
(and (stringp filter) (string-match filter evt))
(and (functionp filter) (funcall filter x))
@@ -8536,7 +8541,9 @@ details and examples."
"\\([0-9]\\{1,2\\}\\)\\([0-9]\\{2\\}\\)\\'" tod)
(concat (match-string 1 tod) ":"
(match-string 2 tod
- (appt-add tod evt)
+ (if warntime
+ (appt-add tod evt warntime)
+ (appt-add tod evt))
(setq cnt (1+ cnt) entries)
(org-release-buffers org-agenda-new-buffers)
(if (eq cnt 0)
Re: [O] get all todo items as lisp list
Hello, Jambunathan K writes: >> Given a todo list in an org file, is there already a function, that >> converts this list to an elisp list, that contains at least heading, >> deadline and properties? > > Create the following interactive function. This functions exports Org > file to a *pretty* lisp file. > > (defun org-export-as-lisp () > (interactive) > (or (featurep 'pp) (require 'pp)) > (let ((out-file >(concat (file-name-sans-extension (buffer-file-name)) ".el"))) > (pp-display-expression (org-element-parse-buffer) "*Org Data*") > (with-current-buffer "*Org Data*" Nice example. Also, the OP may replace (org-element-parse-buffer) with (org-element-parse-buffer 'headline) for quicker results, since parsed headlines already contain all the required information. Regards, -- Nicolas Goaziou
Re: [O] Displaying or linking to definitions of terms?
Hello, jeremiah.do...@gmail.com writes: > I've done a fair amount of reading (and-rereading) the manual, and > searching around, but my search skills are failing me and org-mode is > flexible enough that I figure that someone has either done this, or > there's something that makes it unnecessary that I don't know of. > > I'd like to be able to write a definition of a term, and then be able to > jump to that definition, or see that definition in some way in buffers > where the term occurs. Preferably on a "file can specify a file with > term definitions" or a global scale, but even per-file period would be > awesome. > > I imagine something like a block. In pseudo-org-code: > > #+begin_definition :term elegant > pleasingly graceful and stylish in appearance or manner; pleasingly > ingenious and simple. > #+end_definition > > If there's a way for me to acheive the goal of "find the definition for > this term" in a "this is already idiomatic-org" type of way, I'd love to > hear it. > > If anyone has done something similar, I'd love to hear about it. There are probably a lot of ways to achieve this with included tools. For example, on a per file basis, you may use radio targets: #+begin_src org Contempt for happiness is usually contempt for other people's happiness, and is an elegant hatred for the human race. * Definitions - <<>> :: pleasingly graceful and stylish in appearance or manner; pleasingly ingenious and simple. #+end_src Note that you have to activate <<>> radio target the first time you introduce it (with C-c C-c), but present and future radio targets will be liked to it automatically. Regards, -- Nicolas Goaziou
Re: [O] Bug: [Babel] sqlite if: End of file during parsing
Eric Schulte writes: > > Thanks for the detailed reproduction information in your original email, > it made this issue much easier to solve. I've just pushed up a fix, > please let me know if the problem continues. Eric, seems to work perfectly now. Thank you so much for your help. Phil
Re: [O] Incomplete syntax highlight for C++ code
Hi Eric,
Thank you so much for your reply and helpful suggestions. I looked into the
source of org-mode but as I am not familiar with elisp, I failed to get it.
Then I tried to not load my customized settings and tried org-mode export
again. And finally I found out it was due to another .el I loaded, which is
called highlight-80+ (http://nschum.de/src/emacs/highlight-80+/).
Although I do not know why they conflict, org-mode export function works
perfectly after I disabled highlight-80+. :D But it will be great if
someone is able to and would like to look into this and get a fix to it. As
someone else may encounter the same problem as me.
Thanks,
-Zhiqiu
On Sat, Feb 18, 2012 at 7:21 AM, Eric Schulte wrote:
> Hi Zhiqiu,
>
> First, I would look at the actual text of the exported html code
> example. It likely contains css code specifying how to fontify many
> elements of the code block (e.g., on my system your example exports to
> the following html [1]). You can then add css to your org-mode file
> specifying what colors to use for each code class.
>
> Also, see the `org-export-htmlize-output-type' variable.
>
> Best,
>
> Zhiqiu Kong writes:
>
> > Hi,
> >
> > I am a new org-mode user and am trying to take notes with it. As I put
> > source code into my codes a lot, I love the integration with htmlize
> pretty
> > much. However, I found the syntax highlight on exported html file is not
> > as what I see in Emacs. To be more specific, only comments and string
> > literals are colored, which is shown in http://img.ly/dXTK. And here is
> > what is looks like in Emacs: http://img.ly/dXU6.
> >
> > Actually, what I expected is the keywords such as int, return should at
> > least be colored, which is as introduced by emacs-fu (
> >
> http://emacs-fu.blogspot.com/2009/05/writing-and-blogging-with-org-mode.html
> > ).
> >
> > I checked out the latest org-mode (Org-mode version 7.8.03
> > (release_7.8.03.336.gdf0a9) ) and htmlize (for git repository), but the
> > problem remains. Moreover, here is my project setting:
> >
> > (setq org-publish-project-alist
> > '(("note-org"
> > :base-directory "~/Docs/notes/org/"
> > :publishing-directory "~/Docs/notes/html/"
> > :htmlized-source t
> > :base-extension "org"
> > :sub-superscript nil
> > :recursive t
> > :publishing-function org-publish-org-to-html
> > ;; :org-export-htmlize-output-type "css"
> > :html-extension "html"
> > :auto-index t
> > :index-filename "index.org"
> > :index-title "My Notes"
> > :link-home "index.html"
> > ;; :section-numbers nil
> > :style " > href=\"css/worg.css\"
> > type=\"text/css\"/>")
> > ("note-static"
> > :base-directory "~/Docs/notes/org/"
> > :publishing-directory "~/Docs/notes/html/"
> > :recursive t
> > :base-extension
> > "css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|swf\\|zip\\|gz\\|txt\\|el"
> > :publishing-function org-publish-attachment)
> > ("My Notes"
> > :components ("note-org" "note-static")
> > :auto-sitemap t
> > :auto-index t
> > )))
> >
> > Any suggestion on how to debug and fix this problem? Or this is normal?
> > Thanks a lot!!
> >
> >
> > Thanks,
> > -Zhiqiu
>
>
> Footnotes:
> [1] int
> main(){
> std::cout << style="color: #a5c261;">"hello" << std::endl;
> }
>
>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
