Re: [O] Problem with org-entities-user
Hi Nicolas,
maybe first have to get clear what you mean by "not accepting raw commands".
Would that mean that if I write \vspace in the buffer, the LaTeX exporter
would then give me \textbackslash{}vspace, for example, because i thinks that
I want that text to appear in the output?
- Carsten
On 19 sep. 2012, at 17:55, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik writes:
>
>> These are all valid arguments. However, I did design
>> Org-mode to be LaTeX-near to make sure that it becomes
>> easy and fast to type as a notes environment. In my mind, a user
>> expecting \cite{...} to work in other backends is not necessarily
>> a wrong expectation, and if we introduce a syntax for doing citations
>> in HTML, why not using the LaTeX syntax for it?
>>
>> So actually, it seems I do not fully agree with your *consistency*
>> argument. While you are right that it is the logical and clean thing
>> if you view Org as a markup language created for export, it is not
>> necessarily the right solution for a convenience point of view.
>
> My point is not about removing anything related to LaTeX syntax. I'm
> fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
> long as it really is accepted by most major export back-ends.
>
> But I think accepting raw commands like \vspace, \hfill and al. is not
> necessary (as long as there's still a way to send them to the export
> back-end). We shouldn't trick users into thinking these commands will be
> obeyed in any situation.
>
> Moreover, I don't think that they belong to an easy and fast to type
> notes environment.
>
>
> Regards,
>
> --
> Nicolas Goaziou
- Carsten
Re: [O] [PATCH] Lookup functions for tables
Bastien writes: > The patch is longer than 20 lines, so we would need you to sign the > FSF papers to be able to accept it. Request submitted. -- Jarmo
Re: [O] [PATCH] Lookup functions for tables
Achim Gratz writes: > Well, it doesn't become a TINYCHANGE just because you put that stamp > on it. This patch clearly is over 20 non-trivial lines, so you will > need to assign copyright to the FSF. The program code (one macro and two calls) is less than 20 lines, and I was hoping documentation would not count. Now I know there is no hope. :-) -- Jarmo
Re: [O] [PATCH] Lookup functions for tables
>> I tested the new functions locally, as can be seen from the >> examples. I also ran make without problems. I am, however, unable to >> install org from the git version (for some unknown reason), so I was >> unable to test the final, committed version. > > I can't decode that last part… you installed Org from git with make, > then made your changes (also in git) and now Org does or doesn't do > what when you try to install? Not being able to decode is understandable, because it wasn't very clear. Yesterday my org installation from git did not work, but today, when I took a fresh look at the situation, I was able to notice a path problem which I solved. I now tested the committed version with my changes, and it works. A couple of points about the process: 1. Already yesterday I ran make to make sure that org still compiles ok. It did, although the used cl function 'position' does give two warnings. 2. When I tried to run "make test", it failed because I don't have ERT installed. I am running Emacs 23.3.1, which does not include ERT, and I could not find a package providing ert.el in the repositories of Fedora 16. Because I was running out of time, I decided not to start installing ERT manually. Today I installed ERT by hand, but "make test" still does not work, because the test script runs "emacs -Q" and thus does not load my init file (where the directory of ERT is added to path). I don't want to make a manually installed ERT system-wide, so I had to skip the tests. -- Jarmo
Re: [O] GTD in org mode - in which project is this action ?
Clément Mayet writes: > *I think the main difficulty is to get the project to which the action > belongs as it is only a heading above the action. My first question is > : should I use properties, tags , something else ?* I use properties for projects. Depending on your numbers of concurrent projects, you may want to consider separate files for each project. (IMHO less elegant for a large number of little projects, but nice for say up to ten). > - *scratch.org* (for quicknotes,todos, ideas of projects, to be > organized/refiled later on during the weekly review) I'd add a '* Inbox' Headline at the end of the relevant files, i.e. perso.org, research.org etc. No separate scratch file, no w/pinbox.org. > 3.1.1 project description > ~~ > *Should I put it under another headline (description, outcome) or > directly under the project's headline ? Any thoughts about this ?* Both options seem viable. > * contexts (as few as possible) > Use tags > - :@office: > - :@home: > - :@errands: > - :@offline: Once, I had a tag NET for things I needed to do while online. I then figured out I was online almost everywhere I actually worked, so I don't use it anymore.
Re: [O] Habit setup help needed
Robert Horn writes: > *** HABIT [#A] Weekly GTD review [0/9] > :home: > DEADLINE: <2012-09-21 Fri ++1w> SCHEDULED: <2012-09-17 Mon ++1w> > :LOGBOOK: > - State "DONE" from "HABIT" [2012-09-14 Fri 09:00] > I thought that it should be blue from the asterisk until monday, because > that is the completed period. I think the consistency bar is only fully functional with timestamps of the format <2012-09-13 Do .+7d/10d> : You need a minimum/maximum range. Memnon
[O] Sending commits to Org
Hello, Just a Git question that puzzles me for long about how to send commits per email to Org ML? In the documentation (http://orgmode.org/worg/org-contribute.html), it's written: #+begin_src sh git commit -m "Your message" git format-patch master #+end_src ^^ When I follow it, there is no 0001-patch.txt file created... I must write: #+begin_src sh git format-patch origin/master #+end_src ^ for such patch files to be created. Is it a documentation bug, or some feature of my (Git) installation? Best regards, Seb -- Sebastien Vauban
Re: [O] Problem with org-entities-user
Hello,
Carsten Dominik writes:
> maybe first have to get clear what you mean by "not accepting raw commands".
> Would that mean that if I write \vspace in the buffer, the LaTeX exporter
> would then give me \textbackslash{}vspace, for example, because i thinks that
> I want that text to appear in the output?
Correct. This is the same when you type something in an Org
buffer and call the HTML back-end.
Regards,
--
Nicolas Goaziou
Re: [O] [New Latex Exporter][BABEL][BUG] lists and inline src
Hello,
Eric Schulte writes:
> Does this problem present itself when you execute the inline code block
> interactively, or only when using the new latex exporter? If the later
> then it is a latex exporter bug and not a Babel bug. I've updated the
> subject line so that hopefully the latex export experts will notice this
> message.
Indeed, the parser doesn't understand:
- src_emacs-lisp{(+ 1 2)}
That's a bug. The problem is related to
`org-babel-inline-src-block-regexp', which is used by the parser. More
accurately, at the beginning of that regexp, there is:
"\\(?:^\\|[^-[:alnum:]]\\)\\(src_"
Item contents start at the "s" from "src" but the regexp cannot match
from there. So, is "[^-[:alnum:]]" (and, therefore,
"\\(?:^\\|[^-[:alnum:]]\\)") really necessary? Why couldn't an user be
able to write an inline-src-block in the middle of something (for
example with raw results)?
If checking the character before the inline-src-block object is
mandatory, I'll have to rely on an hack in org-element.el, along the
lines of:
#+begin_src emacs-lisp
(save-excursion
(unless (bolp) (backward-char))
(re-search-forward org-babel-inline-src-block-regexp nil limit)
...)
#+end_src
Obviously, I'd rather have the first part of the regexp removed.
What do you think?
Regards,
--
Nicolas Goaziou
Re: [O] Problem with org-entities-user
On 20 sep. 2012, at 13:57, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik writes:
>
>> maybe first have to get clear what you mean by "not accepting raw commands".
>> Would that mean that if I write \vspace in the buffer, the LaTeX exporter
>> would then give me \textbackslash{}vspace, for example, because i thinks that
>> I want that text to appear in the output?
>
> Correct. This is the same when you type something in an Org
> buffer and call the HTML back-end.
Yes, I see what you mean and it is indeed consistent.
The only thing is: I do use Org to draft documents intended to
be later fine-tuned as LaTeX documents, while I don't usually
do this for other backends. So the ability to put in naked
LaTeX formatting commands does have value and convenience for
me personally.
If the consent will be to remove this for cleanness and exporter
speed, maybe we could leave the code that does the protection
in an allow users to opt-in?
- Carsten
Re: [O] Feature request: setq org-agenda-follow-indirect 'parent
2012/3/31 Nicolas Girard : > > when browsing my TODO items in the agenda, I wish I could display then > in an indirect buffer. > But as I structure my stuff, displaying the tree with a TODO item as > root is often useless. > > Indeed, within my PROJECT items, I differentiate between TODO and > support (notes, references) children ; for instance > #+BEGIN_SRC org > ,* PROJECT My project > ,** References > ,*** Ref 1 > ,*** Ref 2 > ,** Notes > ,*** Note 1 > ,*** Note 2 > ,** TODO Todo item 1 > ,** TODO Todo item 2 > #+END_SRC > > In this example, in order to work on, or even decide anything about > "Todo item 1", chances are that I'd also need to see the contents of > the "References" and "Notes" items ; so the tree I'd need to see in > the indirect buffer should have the *parent* of "Todo item 1" as root, > instead of "Todo item 1" itself. > > It seems rather easy to achieve, since `org-agenda-do-context-action' > calls `org-agenda-tree-to-indirect-buffer', which is supposed to deal > with this case when called with a numerical prefix argument ; so I did > give it a try but couldn't get it to work properly :-( > Hi all, any thoughts about my request ? Thanks in advance, cheers, Nicolas
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Nick Dokos writes: > Achim Gratz wrote: > >> Nick Dokos writes: >> > Loris Bennett wrote: >> >> In the *Org-Babel Error Output* buffer, I get the following: >> >> >> >> /bin/bash: /scpc:x@xx:/tmp/sh-script-7472puH: No such file or >> >> directory >> >> It would seem that you are trying to use a remote file with a local >> bash. That won't work, especially since bash doesn't understand what >> that tramp syntax invoking scpc is about… You need to either invoke that >> script on the remote end or copy the file to local and source it there. >> >> > But probably the best thing to do is to leave org out of it and try opening >> > the file directly: it seems to be a tramp problem. >> >> Sort of, but it wouldn't exist without Babel if I decode the temporary >> filename correctly. >> > > Duh - you are right. OTOH, I don't understand how this could ever have > worked. IIUC, the OP says that he had *something* working, although > revisiting the thread I don't see what that was. > > Nick I used to be able do all sorts of stuff with sh, Perl and R. Now the following example no longer works: ,--- | #+begin_src sh :dir /@:/tmp | echo "Executed by `whoami` on `hostname` in `pwd`" | #+end_src `--- I get the following in *Messages*: ,-- | executing Sh code block... | Tramp: Encoding region using function `base64-encode-region'...done | Tramp: Decoding region into remote file /scpc:@:/tmp/sh-script-4062nYW...done | Tramp: Encoding region using function `base64-encode-region'...done | Tramp: Decoding region into remote file /scpc:@:/tmp/sh-script-4062nYW...done | Babel evaluation exited with code 127 | Code block produced no output. `-- and, as mentioned earlier, the corresponding line in *Org-Babel Error Output* , | bin/bash: /scpc:root@sadmin02:/tmp/sh-script-4062nYW: No such file or directory ` Does this work on other people's systems? Should it work? -- Dr. Loris Bennett (Mr.) ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de
Re: [O] Inline and executing the document
Sorry for not reading the docs carefully enough.
I had overlooked :results wrap
But even with this options things behave strangely.
src_emacs-lisp[:results wrap]{(+ 2 3)} :RESULTS:
5:END:
:RESULTS:
5:END:
:RESULTS:
5:END:
:RESULTS:
5:END:
:RESULTS:
5:END:
Running the code multiple times in the document produces multiple outputs.
I though the whole idea of wrapping was intended to mark results in a way the
are replaces
when the command is reexecuted.
Furthermore, on exporting the keywords :RESULTS: and :END:
are written into the exported document (I tried LaTeX+pdf and HTML)
Am I still misunderstanding something?
Re: [O] org-metaup / org-metadown nerfed in 7.9.1
Thanks Anthony. Looks like that will be helpful if I ever update.
Re: [O] Habit setup help needed
Memnon Anon writes: > > I think the consistency bar is only fully functional with timestamps > of the format <2012-09-13 Do .+7d/10d> : You need a minimum/maximum range. > Thank you. That was the clue I needed. I hadn't made the connection between schedule repeat intervals and deadlines in habits. So I was expecting task deadlines to cover that. I suggest adding the following to item 5. in the habit documentation: A weekly report that must be filed during the following work week could be described with "SCHEDULED: <2012-09-24 Mon +1w/12d>". Have I understood this correctly? It works for the habits that I'm testing, but I haven't figured out the code to be sure that this covers the edge cases properly. Assuming that this is correct, perhaps the info section on dates and times should note that the habit option extends the scheduled time notation. That will catch folks who go to that section directly. Alternatively, a more radical change would be to change habits to use scheduled and deadline in the same sense that they are used elsewhere: scheduled means should start at this time, deadline means should complete at this time. That would affect all current users. Is there an extra capability that this notation adds? R Horn rjh...@alum.mit.edu
Re: [O] LaTeX export problem
Hi, I am having similar problems with LaTeX export. I am exporting source code snippets (XML) which has many variables with underscores in their names. At some point in the process of switching to more recent Org the export started producing incorrect LaTeX so the generation of PDF fails, therefore the functionality is unusable for me. Could you point us to any documentation on how to switch to the new exporter? Is the tutorial http://orgmode.org/worg/org-tutorials/org-latex-export.html still relevant? Thanks Alex On Wed, Sep 19, 2012 at 2:57 AM, Bastien wrote: > Hi Gary, > > Gary Oberbrunner writes: > >> Using a recent git checkout of org-mode (f51c405), the following small >> org-mode file produces invalid LaTeX. I'm pretty sure it used to >> work. The \alpha and \beta seem to be what confuses it. >> >> ---snip >> * Scorecards >> ** Product Releases >> | *Product* | *\alpha* | *\beta* | *Release* | *Status* | >> |---+--+-+---+--| >> | test | a| b | c | d| >> ---snip >> >> Open this with emacs -Q (emacs 24), load org-mode, and C-c C-e C-d to >> export as LaTeX, you get the following error: > > The new LaTeX exporter does the right thing here. > > You can experiment with it or wait until it is part of core. > > Thanks, > > -- > Bastien >
Re: [O] [New Latex Exporter][BABEL][BUG] lists and inline src
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>> Does this problem present itself when you execute the inline code block
>> interactively, or only when using the new latex exporter? If the later
>> then it is a latex exporter bug and not a Babel bug. I've updated the
>> subject line so that hopefully the latex export experts will notice this
>> message.
>
> Indeed, the parser doesn't understand:
>
> - src_emacs-lisp{(+ 1 2)}
>
> That's a bug. The problem is related to
> `org-babel-inline-src-block-regexp', which is used by the parser. More
> accurately, at the beginning of that regexp, there is:
>
> "\\(?:^\\|[^-[:alnum:]]\\)\\(src_"
>
> Item contents start at the "s" from "src" but the regexp cannot match
> from there. So, is "[^-[:alnum:]]" (and, therefore,
> "\\(?:^\\|[^-[:alnum:]]\\)") really necessary? Why couldn't an user be
> able to write an inline-src-block in the middle of something (for
> example with raw results)?
>
Thanks for finding the source of this problem. The preceding character
is checked so that inline source blocks can be commented. E.g., a user
may want =src_sh{date}= to appear verbatim. Similarly if the preceding
character is a letter e.g., notsrc_sh{date}, then the source block
should not be executed.
>
> If checking the character before the inline-src-block object is
> mandatory, I'll have to rely on an hack in org-element.el, along the
> lines of:
>
> #+begin_src emacs-lisp
> (save-excursion
> (unless (bolp) (backward-char))
> (re-search-forward org-babel-inline-src-block-regexp nil limit)
> ...)
> #+end_src
>
> Obviously, I'd rather have the first part of the regexp removed.
>
> What do you think?
>
Ideally there would be a way to specify that *if* a character exists
before the code block it must have some property, or to match the
beginning of the element as another regexp option. I would say we can
go ahead and remove the leading portion of the regexp, but as I recall I
wrote it in response to legitimate complaints on the mailing list about
the overly permissive behavior of inline source blocks, and I do not
want for those problems to re-emerge.
Best,
>
>
> Regards,
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Loris Bennett wrote: > I used to be able do all sorts of stuff with sh, Perl and R. Now the > following example no longer works: > > ,--- > | #+begin_src sh :dir /@:/tmp > | echo "Executed by `whoami` on `hostname` in `pwd`" > | #+end_src > `--- > Just a heads-up: I started bisecting with this example and I can verify that it worked in release_7.8.01 and does not work in release_7.9. I'll continue to bisect. Nick
Re: [O] Inline and executing the document
Neuwirth Erich writes:
> Sorry for not reading the docs carefully enough.
> I had overlooked :results wrap
> But even with this options things behave strangely.
>
> src_emacs-lisp[:results wrap]{(+ 2 3)} :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
>
Inline code blocks are only meant for execution during export. They
were added so that results of code blocks could be inserted inline in
blocks of prose. An example like the above should use a regular code
block.
I would not be surprised if the manual is insufficiently clear on this
point. If you could suggest a placement where wording such as the above
would have been helpful please let me know and I'll update the manual.
Thanks,
>
>
> Running the code multiple times in the document produces multiple outputs.
> I though the whole idea of wrapping was intended to mark results in a way the
> are replaces
> when the command is reexecuted.
>
> Furthermore, on exporting the keywords :RESULTS: and :END:
> are written into the exported document (I tried LaTeX+pdf and HTML)
>
> Am I still misunderstanding something?
>
>
>
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Nick Dokos wrote: > Loris Bennett wrote: > > > I used to be able do all sorts of stuff with sh, Perl and R. Now the > > following example no longer works: > > > > ,--- > > | #+begin_src sh :dir /@:/tmp > > | echo "Executed by `whoami` on `hostname` in `pwd`" > > | #+end_src > > `--- > > > > Just a heads-up: > > I started bisecting with this example and I can verify that > it worked in release_7.8.01 and does not work in release_7.9. > > I'll continue to bisect. > Bisection fingered the following commit, which unfortunately leaves things pretty murky: , | commit 552b0edb254a104e441e28f3a942dc6005e97f87 | Author: Bastien Guerry | Date: Sat Mar 17 15:44:41 2012 +0100 | | Manually revert to 78ec8e21 (Release 7.8.04) | | Let's take a fresh start. Sorry Mama. | | :04 04 163e6eefeae7ce8287a9b95376a182725463b6e4 00f1fc024be6f61d8f7b520be509d46555418adb MEXPERIMENTAL | :100644 100644 1753dd8d44eab0fc512284172e8902302959bbab 1022cdc9ff14c9d7f3004c4181507acf9f7414a2 MMakefile | :100644 100644 ad822658a8954b7d02b79f2cccd9c9b721b3e889 cf67c9933ccbc13676b6b9ded82bb62c3ab67220 MREADME_DIST | :04 04 35c93a0ab0b246483543b14ba3cb218dae9172e1 46f1a162838f9234bf0f34ee202ad88690af8e5e Mcontrib | :04 04 e680a29de46430d26ee79a24abd7ec4f6cec28ba c34f8f62ceced35f6519935bbe0404b95a6d5b4d Mdoc | :04 04 5989cfb368b5bee95e1fcceb42a88c381d72bdee 012e82d1831a339b52148716cd9a1cad7d3159f9 Metc | :04 04 7ef0c8f2ecdd18ef48acfc0e13815ac6e8b01d64 d2895eead691b78d01435a0c9ba45c161e462f39 Mlisp | :04 04 99d7331b0f659fe1b1e6323cb5a33c66152e7d67 e2e86614d689cef98523b2d6f6c8f3b1dea5ddff Mtesting ` Nick
Re: [O] [PATCH] Lookup functions for tables
Hi Jarmo On Wed, Sep 19, 2012 at 6:48 PM, Jarmo Hurri wrote: > --- a/doc/org.texi > +++ b/doc/org.texi > @@ -2399,6 +2399,7 @@ formula, moving these references by arrow keys > * Formula syntax for Lisp:: Writing formulas in Emacs Lisp > * Durations and time values:: How to compute durations and time values > * Field and range formulas::Formula for specific (ranges of) fields > +* Lookup functions::Lookup functions for searching tables > * Column formulas:: Formulas valid for an entire column > * Editing and debugging formulas:: Fixing formulas > * Updating the table:: Recomputing all dependent fields > @@ -2729,7 +2730,7 @@ example above). In my opinion “Field and range formulas” and “Column formulas” should stay together, so I suggest * Field and range formulas::Formula for specific (ranges of) fields * Column formulas:: Formulas valid for an entire column +* Lookup functions::Lookup functions for searching tables for the menu and the corresponding move for the texinfo subsection. Michael
Re: [O] Problem with paragraph fill / tab in lists
On 12-Sep-19, at 4:52 PM, Nick Dokos wrote: > Anthony Lander wrote: > >> >> On 12-Sep-19, at 2:10 PM, Nick Dokos wrote: >> >>> Bastien wrote: >>> Yes -- we'll never say it enough: don't use filladapt.el with org-mode. >>> >>> It's probably worth adding a paragraph about this in the org manual, >>> section Miscellaneous/Interactions/Conflicts. >> >> Nick, the way to turn off filladapt for orgmode is to add the following to >> .emacs: >> >> (add-hook 'org-mode-hook 'turn-off-filladapt-mode) >> >> That might save people some digging for how to do it. >> > > Thanks for that. I added a question to the FAQ with a description of the > problem as I understand it and incorporating Anthony's suggestion above. > Please review and either fix or let me know of any problems. That looks good to me. I'm sure that will save people a lot of frustration. Bastien, since org and filladapt are so incompatible, would you consider adding this as a strong recommendation on this page: http://orgmode.org/manual/Activation.html? -Anthony
Re: [O] [New Latex Exporter][BABEL][BUG] lists and inline src
Hello,
Eric Schulte writes:
> Thanks for finding the source of this problem. The preceding character
> is checked so that inline source blocks can be commented. E.g., a user
> may want =src_sh{date}= to appear verbatim.
=src_sh{date}= won't be expanded by `org-babel-exp-non-block-elements'
(is there another function executing them?) since the current version
checks object at point (in this case, it is a verbatim object, not an
inline-src-block). So, in this case, there's no need for the check.
> Similarly if the preceding character is a letter e.g.,
> notsrc_sh{date}, then the source block should not be executed.
I don't understand why it wouldn't be expanded in that situation. It can
be useful if results are raw: it becomes a beefed-up macro.
> Ideally there would be a way to specify that *if* a character exists
> before the code block it must have some property, or to match the
> beginning of the element as another regexp option. I would say we can
> go ahead and remove the leading portion of the regexp, but as I recall I
> wrote it in response to legitimate complaints on the mailing list about
> the overly permissive behavior of inline source blocks, and I do not
> want for those problems to re-emerge.
I understand, but it looks like a very drastic solution. It may be worth
reconsidering it for 8.x branch. If problems re-emerge then, test cases
will be provided. What do you think about it?
For 7.9.x, I'll just commit the workaround.
Regards,
--
Nicolas Goaziou
Re: [O] Sending commits to Org
Hi, I think you're still on master when you make your changes. git maintains your *local copy* of master as 'master', whereas the original, unchanged upstream branch master is still available as 'origin/master'. You create a patch against a different branch, and since you are on 'master' which differs from 'origin/master', it works like you described. If you first create a branch on your side and switch to it before making changes, you can run format-patch against your local copy of master as well. That is, #+begin_src sh git branch local git checkout local # make your changes git commit -m "Your message" git format-patch master #+end_src ^^ This is also the procedure described in http://orgmode.org/worg/org-contribute.html#sec-4 under *Sending commits, and it should work fine this way. philipp On Thu, Sep 20, 2012 at 01:40:55PM +0200, Sebastien Vauban wrote: > Hello, > > Just a Git question that puzzles me for long about how to send commits per > email to Org ML? > > In the documentation (http://orgmode.org/worg/org-contribute.html), it's > written: > > #+begin_src sh > git commit -m "Your message" > git format-patch master > #+end_src ^^ > > When I follow it, there is no 0001-patch.txt file created... > > I must write: > > #+begin_src sh > git format-patch origin/master > #+end_src ^ > > for such patch files to be created. Is it a documentation bug, or some feature > of my (Git) installation? > > Best regards, > Seb > > > -- > Sebastien Vauban > >
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Nick Dokos wrote: > Nick Dokos wrote: > > > Loris Bennett wrote: > > > > > I used to be able do all sorts of stuff with sh, Perl and R. Now the > > > following example no longer works: > > > > > > ,--- > > > | #+begin_src sh :dir /@:/tmp > > > | echo "Executed by `whoami` on `hostname` in `pwd`" > > > | #+end_src > > > `--- > > > > > > > Just a heads-up: > > > > I started bisecting with this example and I can verify that > > it worked in release_7.8.01 and does not work in release_7.9. > > > > I'll continue to bisect. > > > > Bisection fingered the following commit, which unfortunately > leaves things pretty murky: > > , > | commit 552b0edb254a104e441e28f3a942dc6005e97f87 > | Author: Bastien Guerry > | Date: Sat Mar 17 15:44:41 2012 +0100 > | > | Manually revert to 78ec8e21 (Release 7.8.04) > | > | Let's take a fresh start. Sorry Mama. > | > ` > OK. It was working in 7.8.03, broken in 7.8.04, fixed in 7.8.05 and broken again in 7.8.11 when Bastien reverted to 7.8.04 (I presume to clean up a mess: I don't remember the details). >From 7.8.03 to 7.8.04, it broke with the following commit: , | 5cb80c7e5b9bcae180b799d2a49c78d529e029f0 is the first bad commit | commit 5cb80c7e5b9bcae180b799d2a49c78d529e029f0 | Author: Eric Schulte | Date: Mon Mar 12 13:23:53 2012 -0400 | | apply :shebang and :padline to shell script execution | | * lisp/ob-sh.el (org-babel-execute:sh): Pass all params to subroutine. | (org-babel-sh-evaluate): Apply :shebang and :padline to shell script | execution. | ` I haven't chased it all the way down because the reverts are making my head spin, but it may be that somehow the above commit got lost somewhere - or it got fixed and then the big revert lost the fix. Maybe Eric or Bastien remembers what happened. Nick
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Nick Dokos wrote: > I haven't chased it all the way down because the reverts are > making my head spin, but it may be that somehow the above commit > got lost somewhere - or it got fixed and then the big revert lost > the fix. Maybe Eric or Bastien remembers what happened. > This doesn't make sense (I blame the head-spinning reverts :-) ), so let me try again: Eric's commit broke it between 7.8.03 and 7.8.04. It got fixed somehow, either because of a revert or because some fix was actually applied, I don't know which. It was working until 7.8.10 and then Bastien's commit reverted to (broken) 7.8.04, so from 7.8.11- on the breakage exists. So if there was a fix, we need to find it and reapply. If not, someone (presumably Eric) will need to take a look and possibly develop a fix. Nick
Re: [O] [New Latex Exporter][BABEL][BUG] lists and inline src
Nicolas Goaziou writes:
> Hello,
>
> Eric Schulte writes:
>
>> Thanks for finding the source of this problem. The preceding character
>> is checked so that inline source blocks can be commented. E.g., a user
>> may want =src_sh{date}= to appear verbatim.
>
> =src_sh{date}= won't be expanded by `org-babel-exp-non-block-elements'
> (is there another function executing them?) since the current version
> checks object at point (in this case, it is a verbatim object, not an
> inline-src-block). So, in this case, there's no need for the check.
>
>> Similarly if the preceding character is a letter e.g.,
>> notsrc_sh{date}, then the source block should not be executed.
>
> I don't understand why it wouldn't be expanded in that situation. It can
> be useful if results are raw: it becomes a beefed-up macro.
>
>> Ideally there would be a way to specify that *if* a character exists
>> before the code block it must have some property, or to match the
>> beginning of the element as another regexp option. I would say we can
>> go ahead and remove the leading portion of the regexp, but as I recall I
>> wrote it in response to legitimate complaints on the mailing list about
>> the overly permissive behavior of inline source blocks, and I do not
>> want for those problems to re-emerge.
>
> I understand, but it looks like a very drastic solution. It may be worth
> reconsidering it for 8.x branch. If problems re-emerge then, test cases
> will be provided. What do you think about it?
>
> For 7.9.x, I'll just commit the workaround.
>
Yea, that sounds reasonable, thanks for taking care of this. If I find
time I'll dig through the mailing list and see if I can find the exact
reason why that portion of the regexp was added.
I've had the experience before of reverting a piece of code that seemed
superfluous to then have old bugs re-emerge and finally revert my
reversion. So I now try to err on the side of deference towards
existing code.
Cheers,
>
>
> Regards,
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Nick Dokos writes: > Nick Dokos wrote: > >> I haven't chased it all the way down because the reverts are >> making my head spin, but it may be that somehow the above commit >> got lost somewhere - or it got fixed and then the big revert lost >> the fix. Maybe Eric or Bastien remembers what happened. >> > > This doesn't make sense (I blame the head-spinning reverts :-) ), so let > me try again: Eric's commit broke it between 7.8.03 and 7.8.04. It got > fixed somehow, either because of a revert or because some fix was > actually applied, I don't know which. It was working until 7.8.10 and > then Bastien's commit reverted to (broken) 7.8.04, so from 7.8.11- on > the breakage exists. > > So if there was a fix, we need to find it and reapply. If not, someone > (presumably Eric) will need to take a look and possibly develop a fix. > I've spent some time looking at this. A couple of things are happening. Back in the time of 7.8.03 and 7.8.04, the org-babel-execute:sh call happened in such a context that all external function calls would take place on the remote machine if the :dir header specified a tramp path to a remote machine. This is true both before and after my 5cb80c7e5b9bca commit. However this has changed between then and now, meaning that reverting the 5cb80c7e5b9bca commit now will not solve this problem. In the current branch there is no change of context s.t. external calls made by the org-babel-execute:* functions happen by default on the remote machine. I think this is the real problem. Perhaps it would be possible to git bisect with another language like perl? Sorry I'm not more help here, the remote-execution magic was mainly implemented by Dan Davison. Best, > > Nick > > > -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Org-mode release 7.9
Bastien writes: >> However I suggest to lose the plural >> and just use `org-plus-contrib´. > > Yes, that's fine for me. Thanks, Implemented and pushed. 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] [PATCH] Lookup functions for tables
Jarmo Hurri writes: > 2. When I tried to run "make test", it failed because I don't have ERT >installed. I am running Emacs 23.3.1, which does not include ERT, and >I could not find a package providing ert.el in the repositories of >Fedora 16. Because I was running out of time, I decided not to start >installing ERT manually. Add this to local.mk: BTEST_POST = -L /path/to/ert I keep this installed in testing/ert for historical reasons. Get the latest version for emacs 23 from: https://github.com/ohler/ert Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Inline and executing the document
Thank you,
this clarified things for me!
I will look and suggest a place for mentioning this in the docs.
Erich
On Sep 20, 2012, at 4:23 PM, Neuwirth Erich wrote:
> Sorry for not reading the docs carefully enough.
> I had overlooked :results wrap
> But even with this options things behave strangely.
>
> src_emacs-lisp[:results wrap]{(+ 2 3)} :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
> :RESULTS:
> 5:END:
>
>
> Running the code multiple times in the document produces multiple outputs.
> I though the whole idea of wrapping was intended to mark results in a way the
> are replaces
> when the command is reexecuted.
>
> Furthermore, on exporting the keywords :RESULTS: and :END:
> are written into the exported document (I tried LaTeX+pdf and HTML)
>
> Am I still misunderstanding something?
>
>
>
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Nick Dokos writes: > This doesn't make sense (I blame the head-spinning reverts :-) ), so let > me try again: Eric's commit broke it between 7.8.03 and 7.8.04. It got > fixed somehow, either because of a revert or because some fix was > actually applied, I don't know which. It was working until 7.8.10 and > then Bastien's commit reverted to (broken) 7.8.04, so from 7.8.11- on > the breakage exists. What are you talking about? I don't see any revert between 7.8.10 and 7.8.11? You need to be careful with bisecting acroess fixups, you should "skip" such commits (also commits that don't build, etc.). 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] [New Latex Exporter][BABEL][BUG] lists and inline src
Eric Schulte writes: > Yea, that sounds reasonable, thanks for taking care of this. If I find > time I'll dig through the mailing list and see if I can find the exact > reason why that portion of the regexp was added. That would be a great starting point to avoid repeating past mistakes. > I've had the experience before of reverting a piece of code that seemed > superfluous to then have old bugs re-emerge and finally revert my > reversion. So I now try to err on the side of deference towards > existing code. I know the feeling. But I'm pretty confident on this one. BTW, the bug should be fixed in 7.9.x now. Regards,
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Achim Gratz wrote: > Nick Dokos writes: > > This doesn't make sense (I blame the head-spinning reverts :-) ), so let > > me try again: Eric's commit broke it between 7.8.03 and 7.8.04. It got > > fixed somehow, either because of a revert or because some fix was > > actually applied, I don't know which. It was working until 7.8.10 and > > then Bastien's commit reverted to (broken) 7.8.04, so from 7.8.11- on > > the breakage exists. > > What are you talking about? I don't see any revert between 7.8.10 and > 7.8.11? You need to be careful with bisecting acroess fixups, you > should "skip" such commits (also commits that don't build, etc.). > I may be confused but what I'm talking about is tags on the master branch: commit 552b0edb254a104e441e28f3a942dc6005e97f87 came between the tags "release_7.8.10" and "release_7.8.11" on the master branch: $ git log release_7.8.10..release_7.8.11 | grep 552b0edb254a104e441e28f3a942dc6005e97f87 commit 552b0edb254a104e441e28f3a942dc6005e97f87 Nick
[O] org-e-groff-export-to-groff produces empty output file
Hi, Maybe I'm missing something obvious here, but I can't get org-e-groff to generate anything but an empty output file. I've boiled this down to the following minimal example. First save the attached example.org file to /tmp/example.org. Then run the following in your shell, # -*- shell-script -*- emacs --batch --eval '(let ((org-path "~/.emacs.d/src/org-mode/")) (add-to-list (quote load-path) (expand-file-name "lisp" org-path)) (add-to-list (quote load-path) (expand-file-name "contrib/lisp" org-path)) (require (quote org)) (require (quote org-e-groff)))' /tmp/example.org -f org-e-groff-export-to-groff The above generates an empty file in /tmp/example.groff. What am I missing? Thanks, #+Title: Example Org-mode file #+Author: Eric Schulte This Org-mode file is intended as illustration. * Here is one headline Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. * Here is another headline - foo - bar - baz -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Nick Dokos writes: > Achim Gratz wrote: > >> Nick Dokos writes: >> > This doesn't make sense (I blame the head-spinning reverts :-) ), so let >> > me try again: Eric's commit broke it between 7.8.03 and 7.8.04. It got >> > fixed somehow, either because of a revert or because some fix was >> > actually applied, I don't know which. It was working until 7.8.10 and >> > then Bastien's commit reverted to (broken) 7.8.04, so from 7.8.11- on >> > the breakage exists. >> >> What are you talking about? I don't see any revert between 7.8.10 and >> 7.8.11? You need to be careful with bisecting acroess fixups, you >> should "skip" such commits (also commits that don't build, etc.). >> > > I may be confused but what I'm talking about is tags on the master > branch: commit 552b0edb254a104e441e28f3a942dc6005e97f87 came between the > tags "release_7.8.10" and "release_7.8.11" on the master branch: That's a trap: the release tag for 7.8.11 is on the wrong side of the merge and as a result you're pulling in the complete history of commits that are in one branch, but not the other and that includes the botched merge before 7.8.04. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Invalid function: with-parsed-tramp-file-name with Perl
Achim Gratz wrote: > Nick Dokos writes: > > Achim Gratz wrote: > > > >> Nick Dokos writes: > >> > This doesn't make sense (I blame the head-spinning reverts :-) ), so let > >> > me try again: Eric's commit broke it between 7.8.03 and 7.8.04. It got > >> > fixed somehow, either because of a revert or because some fix was > >> > actually applied, I don't know which. It was working until 7.8.10 and > >> > then Bastien's commit reverted to (broken) 7.8.04, so from 7.8.11- on > >> > the breakage exists. > >> > >> What are you talking about? I don't see any revert between 7.8.10 and > >> 7.8.11? You need to be careful with bisecting acroess fixups, you > >> should "skip" such commits (also commits that don't build, etc.). > >> > > > > I may be confused but what I'm talking about is tags on the master > > branch: commit 552b0edb254a104e441e28f3a942dc6005e97f87 came between the > > tags "release_7.8.10" and "release_7.8.11" on the master branch: > > That's a trap: the release tag for 7.8.11 is on the wrong side of the > merge and as a result you're pulling in the complete history of commits > that are in one branch, but not the other and that includes the botched > merge before 7.8.04. > > OK. Is there no way to fix that? That's pretty confusing. And how can I tell that I have fallen into this trap? Nick
[O] org-wikinodes - is there a limit of processable files/nodes
Hi list, I'm trying to setup org-wikinodes, and I have a directory with hundres of org files and each of them has dozens+ nodes. It looks as if org-wikinode can't build the wiki cache data-structure for that many files/nodes, because it never finds the headlines. Am I missing something? Thanks in advance, - Marcelo.
[O] tag search broken
Hello guys,
My tag search is broken, for some reason. When I search for "tag1" for
example, the search breaks and I get the following message in the
*Messages* buffer:
if: Wrong type argument: stringp, ("tag0" "tag1" "tag3" "tag4")
Here's the backtrace:
Debugger entered--Lisp error: (wrong-type-argument stringp ("haxe" "ruby"
> "blog" "coffeinthevein"))
> string-match("\\[\\[\\([^][]+\\)\\]\\(\\[\\([^][]+\\)\\]\\)?\\]" ("haxe"
> "ruby" "blog" "coffeinthevein"))
> (if (string-match org-bracket-link-regexp category) (progn (setq l ...)
> (when ... ... ...)) (if (and org-prefix-category-max-length ...) (setq
> category ...)))
> (let* ((category ...) (category-icon ...) (category-icon ...) (tag ...)
> time effort neffort (ts ...) (time-of-day ...) stamp plain s0 s1 s2 rtn srp
> l duration thecategory) (and (derived-mode-p ...) buffer-file-name
> (add-to-list ... buffer-file-name)) (when (and dotime time-of-day) (when
> ... ... ...) (if s1 ...) (if s2 ...) (when ... ...) (when s2 ...)) (when
> (string-match ... txt) (if ... ... ...)) (when (derived-mode-p ...) (setq
> effort ...) (when effort ...)) (or effort (setq effort "")) (when remove-re
> (while ... ...)) (add-text-properties 0 (length txt) (quote ...) txt) (setq
> time (cond ... ... ...) extra (or ... "") category (if ... ... category)
> thecategory (copy-sequence category)) (if (string-match
> org-bracket-link-regexp category) (progn ... ...) (if ... ...)) (setq rtn
> (concat ... txt)) (remove-text-properties 0 (length rtn) (quote ...) rtn)
> (org-add-props rtn nil (quote org-category) (if thecategory ... category)
> (quote tags) (mapcar ... tags) (quote org-highest-priority)
> org-highest-priority (quote org-lowest-priority) org-lowest-priority (quote
> time-of-day) time-of-day (quote duration) duration (quote effort) effort
> (quote effort-minutes) neffort (quote txt) txt (quote time) time (quote
> extra) extra (quote format) org-prefix-format-compiled (quote dotime)
> dotime))
> (progn (setq txt (org-trim txt)) (setq txt
> (org-agenda-fix-displayed-tags txt tags org-agenda-show-inherited-tags
> org-agenda-hide-tags-regexp)) (let* (... ... ... ... time effort neffort
> ... ... stamp plain s0 s1 s2 rtn srp l duration thecategory) (and ...
> buffer-file-name ...) (when ... ... ... ... ... ...) (when ... ...) (when
> ... ... ...) (or effort ...) (when remove-re ...) (add-text-properties 0
> ... ... txt) (setq time ... extra ... category ... thecategory ...) (if ...
> ... ...) (setq rtn ...) (remove-text-properties 0 ... ... rtn)
> (org-add-props rtn nil ... ... ... ... ... org-highest-priority ...
> org-lowest-priority ... time-of-day ... duration ... effort ... neffort ...
> txt ... time ... extra ... org-prefix-format-compiled ... dotime)))
> (unwind-protect (progn (setq txt ...) (setq txt ...) (let* ... ... ...
> ... ... ... ... ... ... ... ... ... ...)) (set-match-data
> save-match-data-internal (quote evaporate)))
> (let ((save-match-data-internal ...)) (unwind-protect (progn ... ...
> ...) (set-match-data save-match-data-internal ...)))
> (save-match-data (setq txt (org-trim txt)) (setq txt
> (org-agenda-fix-displayed-tags txt tags org-agenda-show-inherited-tags
> org-agenda-hide-tags-regexp)) (let* (... ... ... ... time effort neffort
> ... ... stamp plain s0 s1 s2 rtn srp l duration thecategory) (and ...
> buffer-file-name ...) (when ... ... ... ... ... ...) (when ... ...) (when
> ... ... ...) (or effort ...) (when remove-re ...) (add-text-properties 0
> ... ... txt) (setq time ... extra ... category ... thecategory ...) (if ...
> ... ...) (setq rtn ...) (remove-text-properties 0 ... ... rtn)
> (org-add-props rtn nil ... ... ... ... ... org-highest-priority ...
> org-lowest-priority ... time-of-day ... duration ... effort ... neffort ...
> txt ... time ... extra ... org-prefix-format-compiled ... dotime)))
> (let* ((bindings ...) (formatter ...)) (loop for (var value) in bindings
> do (set var value)) (save-match-data (setq txt ...) (setq txt ...) (let*
> ... ... ... ... ... ... ... ... ... ... ... ... ...)))
> org-agenda-format-item("" #("cyberchrist haxe engine vs jekyll -- a nice
> way to see what's haxe is capable of and what is missing from ruby
> :haxe:ruby:blog:coffeinthevein:" 0 142 (org-category "someday_maybe"
> fontified nil)) "someday_maybe" ("haxe" "ruby" "blog" "coffeinthevein"))
> (setq txt (org-agenda-format-item "" (concat ... ...) category
> tags-list) priority (org-get-priority txt))
> (cond ((eq action ...) (and org-highlight-sparse-tree-matches ... ...
> ...) (org-show-context ...)) ((eq action ...) (setq txt ... priority ...)
> (goto-char lspos) (setq marker ...) (org-add-props txt props ... marker ...
> marker ... category ... todo ... priority ... "tagsmatch") (push txt rtn))
> ((functionp action) (setq org-map-continue-from nil) (save-excursion ...
> ...)) (t (error "Invalid action")))
> (progn (cond (... ... ...) (... ... ... ... ... ...) (... ... ...) (t
> ...)) (unless org-tags-match-list-su
Re: [O] Using org-mode for laboratory notes.
At Wed, 19 Sep 2012 12:08:21 -0500,
Russell Adams wrote:
On Wed, Sep 19, 2012 at 09:15:35AM -0700, Eric Lubeck wrote:
> One of my particular concerns is this: I'm accustomed to using a
> chronological laboratory notebook for recording all of my data. The
> agenda views in org-mode seem to provide a means to retrieve
> chronological information out of my outlines, but I would than need
> to timestamp every single entry in my outline. Is there a means for
> doing this? Currently I am manually typing C-u C-c ! , but it would
> be helpful to have something automatically configured to timestamp
> and place the time in a drawer for any entry in a particular file.
Hello,
I have the following setup in order to keep cronological notes.
* In my capture templates I have the following :
#+begin_src elisp
("j" "Journal entry" entry
(file make-journal-file-name )
"* %? :journal:REVIEW: \n %u")
#+end_src
and I've defined the function like so :
#+begin_src elisp
(defun make-journal-file-name ()
(concat "~/Planner/Journal/" (format-time-string "%Y.%m.%d.%a" nil) ".org"
)
)
#+end_src
That way, to create a new entry I just hit 'C-c c j'
which gives me the following :
* :journal:REVIEW:
[2012-09-20 Thu]
in the file ~/Planner/Journal/2012.09.20.Thu.org
Please let me know if any of that is unclear.
Hope that helps,
-T
Re: [O] Using org-mode for laboratory notes.
Hey,
this is a nice idea and makes me wonder if it would be possible to use
templates to automatically commit all recent changes in a git repro,
and start a new day by a new fresh working space in git.
git links are already possible. The template could create a link to
the just checked in status in a extra org-file. You would end-up with
a link for each date and file that changed and following this links,
your files would magically be set-back to that particular timestamp.
Furthermore, having the capabilities to see the diff and to see the
history of not only complete files but of single headlines in org-mode
would be then very helpful.
I believe having a more tied integration of git capabilities within
org-mode could really come up with some nice solutions.
Torsten
On 21 September 2012 11:09, Tim wrote:
> At Wed, 19 Sep 2012 12:08:21 -0500,
> Russell Adams wrote:
>
> On Wed, Sep 19, 2012 at 09:15:35AM -0700, Eric Lubeck wrote:
>> One of my particular concerns is this: I'm accustomed to using a
>> chronological laboratory notebook for recording all of my data. The
>> agenda views in org-mode seem to provide a means to retrieve
>> chronological information out of my outlines, but I would than need
>> to timestamp every single entry in my outline. Is there a means for
>> doing this? Currently I am manually typing C-u C-c ! , but it would
>> be helpful to have something automatically configured to timestamp
>> and place the time in a drawer for any entry in a particular file.
>
> Hello,
>
>I have the following setup in order to keep cronological notes.
>
> * In my capture templates I have the following :
>
> #+begin_src elisp
> ("j" "Journal entry" entry
> (file make-journal-file-name )
> "* %? :journal:REVIEW: \n %u")
> #+end_src
>and I've defined the function like so :
>
> #+begin_src elisp
>(defun make-journal-file-name ()
> (concat "~/Planner/Journal/" (format-time-string "%Y.%m.%d.%a" nil)
> ".org" )
> )
> #+end_src
> That way, to create a new entry I just hit 'C-c c j'
>
> which gives me the following :
> * :journal:REVIEW:
> [2012-09-20 Thu]
>
> in the file ~/Planner/Journal/2012.09.20.Thu.org
>
> Please let me know if any of that is unclear.
>
>
> Hope that helps,
>
> -T
>
Re: [O] Using org-mode for laboratory notes.
At Fri, 21 Sep 2012 11:20:41 +0900, Torsten Wagner wrote: > > Hey, > > this is a nice idea and makes me wonder if it would be possible to use > templates to automatically commit all recent changes in a git repro, > and start a new day by a new fresh working space in git. > git links are already possible. The template could create a link to > the just checked in status in a extra org-file. You would end-up with > a link for each date and file that changed and following this links, > your files would magically be set-back to that particular timestamp. > Furthermore, having the capabilities to see the diff and to see the > history of not only complete files but of single headlines in org-mode > would be then very helpful. I suppose we could use call-process in the function to run the git commands ? -- -T
[O] Bug: :clock-in not working in org-capture-templates [7.9.1 (release_7.9.1-274-g2f4d76)]
Hi there,
I find :clock-in not work in org-capture-templates, with initial empty heading:
(setq org-capture-templates
'(("j" "Journal" entry (file+datetree "")
"* %?\n%U\n%i\n" :clock-in t :clock-resume t)))
I proposed the patch:
Modified lisp/org-clock.el
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index b8db2d1..674a5d7 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1180,7 +1180,8 @@ make this the default behavior.)"
(cond ((and org-clock-heading-function
(functionp org-clock-heading-function))
(funcall org-clock-heading-function))
- ((looking-at org-complex-heading-regexp)
+ ((and (looking-at org-complex-heading-regexp)
+ (match-string 4))
(replace-regexp-in-string
"\\[\\[.*?\\]\\[\\(.*?\\)\\]\\]" "\\1"
(match-string 4)))
Thanks
Emacs : GNU Emacs 24.2.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
of 2012-08-31 on tchip-levcom
Package: Org-mode version 7.9.1 (release_7.9.1-274-g2f4d76 @
/home/zslevin/sd/emacs24-starter-kit/src/org-mode/lisp/)
Re: [O] tag search broken
Marcelo de Moraes Serpa wrote:
> Hello guys,
>
> My tag search is broken, for some reason. When I search for "tag1" for
> example, the search breaks
> and I get the following message in the *Messages* buffer:
>
> if: Wrong type argument: stringp, ("tag0" "tag1" "tag3" "tag4")
>
> Here's the backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp ("haxe" "ruby"
> "blog"
> "coffeinthevein"))
> string-match("\\[\\[\\([^][]+\\)\\]\\(\\[\\([^][]+\\)\\]\\)?\\]"
> ("haxe" "ruby" "blog"
> "coffeinthevein"))
> (if (string-match org-bracket-link-regexp category) (progn (setq l ...)
> (when ... ... ...))
> (if (and org-prefix-category-max-length ...) (setq category ...)))
>
> org-agenda-format-item("" #("cyberchrist haxe engine vs jekyll -- a
> nice way to see what's
> haxe is capable of and what is missing from ruby
> :haxe:ruby:blog:coffeinthevein:" 0 142
> (org-category "someday_maybe" fontified nil)) "someday_maybe" ("haxe"
> "ruby" "blog"
> "coffeinthevein"))
^level argument missing
> (setq txt (org-agenda-format-item "" (concat ... ...) category
> tags-list) priority
> (org-get-priority txt))
>
> I can't remember exactly when it started, but I don't remember messing with
> org sources or
> installing additional elisp pacakges in the last days.
>
> Does anyone know what could be wrong?
>
There is a mismatch between the call and the definition of
org-agend-format-item:
it recently acquired an extra argument "level" and apparently it is expecting
it:
,
| (defun org-agenda-format-item (extra txt &optional level category tags dotime
|remove-re habitp)
`
but the call in org-scan-tags does not pass it. So everything got shifted and
when it gets to
,
| (if (string-match org-bracket-link-regexp category)
`
instead of the category, it tries to do the match on the tags list with
predictable results.
What causes this is not clear however: check org.el:org-scan-tags to make
sure that the call to org-agenda-format-item includes the level argument.
That sounds unlikely however.
My guess is that you missed a step after some update: a remake and
starting with a fresh emacs will probably cure it.
Nick
Re: [O] tag search broken
Nick Dokos wrote: > What causes this is not clear however: check org.el:org-scan-tags to make > sure that the call to org-agenda-format-item includes the level argument. > That sounds unlikely however. > Geez - I'm doing a hash of things today. The scenario I was envisaging was that org-agenda.el was updated (so org-agenda-format-item needs the new level arg) but org.el was not (so org-scan-tags calls it *without* the level argument). That's what sounded unlikely to me. But it might not be that far-fetched: there *were* some problems in this area and you might have updated at the "wrong" time. So do check, and if necessary, update to latest before rebuilding and starting with a fresh emacs. Nick
Re: [O] Org HTML->PDF publishing
Thank you for the suggestion guys. It looks as if most of the free solutions don't produce a very good output. Prince does look very good, but it's way too much expensive. I think using org and exporting to both HTML and learning just enough LaTeX in order to export a well formatted output with a nice typography is what I'm going to do. Geez, orgmode is a publishing powerhouse :) Cheers, - Marcelo. On Wed, Sep 19, 2012 at 10:31 AM, Srinivas wrote: > You might want to take a look at http://www.princexml.com/ > > It allows you to specify css and then print to PDF using a command line > tool. > > > >
Re: [O] babel for ditaa-eps
Eric Schulte writes: > "Arne Babenhauserheide (IMK)" writes: > >> Hi Eric, >> >> It’s much easier to answer, what this does not share with ob-ditaa.el :) >> >> If I cut out the obvious renaming (to be able to use a ditaa-exp >> source type), it’s just this diff (and the first half of that only >> defines variables…): >> > > Hi Arne, > > I re-worked your diff into a patch against ob-ditaa.el which adds an > :eps header argument to ditaa code blocks. Please try this out and let > me know if it works and if it loses any functionality from your original > ob-ditaa-eps.el. > > Should we distribute the DitaaEps.jar with Org-mode in the same manner > as we now distribute ditaa.jar? Is it possible to distribute DitaaEps.jar with Org? Or, does it need to be installed separately? All the best, Tom > > From 643d59bfebc2a917bdd4b5da002df4b663f65be2 Mon Sep 17 00:00:00 2001 > From: Eric Schulte > Date: Thu, 13 Sep 2012 08:58:31 -0600 > Subject: [PATCH] adding :eps header argument to ditaa code blocks > > Use of this header argument will change the back-end engine from > ditaa.jar to a combination of DitaaEps.jar and epstopdf. > > This patch is based off of ob-ditaa-eps.el sent to the mailing list by > Arne Babenhauserheide (IMK). > --- > lisp/ob-ditaa.el | 15 +-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el > index 1c6c712..3fbf50b 100644 > --- a/lisp/ob-ditaa.el > +++ b/lisp/ob-ditaa.el > @@ -57,6 +57,9 @@ >:group 'org-babel >:type 'string) > > +(defcustom org-ditaa-eps-jar-path > + (expand-file-name "DitaaEps.jar" (file-name-nondirectory > org-ditaa-jar-path))) > + > (defcustom org-ditaa-jar-option "-jar" >"Option for the ditaa jar file. > Do not leave leading or trailing spaces in this string." > @@ -76,16 +79,24 @@ This function is called by `org-babel-execute-src-block'." >(cmdline (cdr (assoc :cmdline params))) >(java (cdr (assoc :java params))) >(in-file (org-babel-temp-file "ditaa-")) > + (eps (cdr (assoc :eps params))) >(cmd (concat "java " java " " org-ditaa-jar-option " " > (shell-quote-argument > -(expand-file-name org-ditaa-jar-path)) > +(expand-file-name > + (if eps org-ditaa-eps-jar-path org-ditaa-jar-path))) > " " cmdline > " " (org-babel-process-file-name in-file) > - " " (org-babel-process-file-name out-file > + " " (org-babel-process-file-name out-file))) > + (eps-cmd (when eps > + (concat > + "epstopdf" > + " " (org-babel-process-file-name (concat in-file ".eps")) > + " -o=" (org-babel-process-file-name out-file) > (unless (file-exists-p org-ditaa-jar-path) >(error "Could not find ditaa.jar at %s" org-ditaa-jar-path)) > (with-temp-file in-file (insert body)) > (message cmd) (shell-command cmd) > +(when eps (message eps-cmd) (shell-command eps-cmd)) > nil)) ;; signal that output has already been written to file > > (defun org-babel-prep-session:ditaa (session params) > -- > 1.7.12 -- Thomas S. Dye http://www.tsdye.com
Re: [O] [PATCH] Lookup functions for tables
>> --- a/doc/org.texi >> +++ b/doc/org.texi >> @@ -2399,6 +2399,7 @@ formula, moving these references by arrow keys >> * Formula syntax for Lisp:: Writing formulas in Emacs Lisp >> * Durations and time values:: How to compute durations and time values >> * Field and range formulas::Formula for specific (ranges of) fields >> +* Lookup functions::Lookup functions for searching tables >> * Column formulas:: Formulas valid for an entire column >> * Editing and debugging formulas:: Fixing formulas >> * Updating the table:: Recomputing all dependent fields >> @@ -2729,7 +2730,7 @@ example above). > > In my opinion “Field and range formulas” and “Column formulas” should > stay together, so I suggest > > * Field and range formulas::Formula for specific (ranges of) fields > * Column formulas:: Formulas valid for an entire column > +* Lookup functions::Lookup functions for searching tables > > for the menu and the corresponding move for the texinfo subsection. Ok. I guess this also means changing the (next,prev,up) parts of @node-commands. Do you want me to make the change and submit a new patch? -- Jarmo
Re: [O] tag search broken
Updating to git HEAD solved the problem. Thanks! - Marcelo. On Thu, Sep 20, 2012 at 10:36 PM, Nick Dokos wrote: > Nick Dokos wrote: > > > What causes this is not clear however: check org.el:org-scan-tags to make > > sure that the call to org-agenda-format-item includes the level argument. > > That sounds unlikely however. > > > > Geez - I'm doing a hash of things today. The scenario I was envisaging > was that org-agenda.el was updated (so org-agenda-format-item needs the > new level arg) but org.el was not (so org-scan-tags calls it *without* > the level argument). That's what sounded unlikely to me. > > But it might not be that far-fetched: there *were* some problems in this > area and you might have updated at the "wrong" time. So do check, and if > necessary, update to latest before rebuilding and starting with a fresh > emacs. > > Nick > >
Re: [O] [PATCH] Lookup functions for tables
Hi Jarmo On Fri, Sep 21, 2012 at 7:44 AM, Jarmo Hurri wrote: > Ok. I guess this also means changing the (next,prev,up) parts of > @node-commands. Yes. > Do you want me to make the change and submit a new patch? Yes please, I suggest to wait a bit if there will be more comments. Michael
