[O] fontification of blocks inside blocks
Hello,
I've just had to write an org block inside another org block, which
looks like this:
#+attr_latex: :options {0.5\textwidth}
#+begin_column
#+begin_src ocaml
let o1 = object
method m = 0
method p = "foo"
end;;
#+end_src
#+end_column
Unfortunately when I do so I lose the nice fontification of the ocaml
code inside the inner block. Is there a way to get it back?
Now for why I'm doing this and not using the usual headline with a
"column" property: I want to put a vertical bar between the columns, so
I need a "\vrule" after the first column is closed. Using headlines does
not let me write anything between the columns.
Thanks,
Alan
Re: [O] How can I continue my code listing in Beamer slides?
etimecowboy writes:
> Hi everyone,
>
> I have a question about beamer export in org.
>
> I have some code to be put in my slides. The problem is that one slide
> (or one column block) does not have enough space for it. How can I split
> it into two slides or several column blocks? Please help me with it.
>
> etimecowboy
This is what I recently did to have the result of an evaluation (a
fancy verbatim block) on two slides:
--8<---cut here---start->8---
#+latex_header: \usepackage{multicol}
#+BEGIN_LaTeX
\begin{multicols}{2}
#+END_LaTeX
#+results: huffman_res
#+BEGIN_LaTeX
\end{multicols}
#+END_LaTeX
--8<---cut here---end--->8---
Hope this helps,
Alan
Re: [O] [ANN] Lazy cache synchronization
> Nicolas Goaziou writes: > > Now, synchronization happens lazily, which means the cache is only > > updated when and where needed, or during idle time. Therefore the cache > > mechanism scales a lot better. > I had been regularly tracking the performance of org-mode for big files, e.g. a 18 Mb one with 380k lines (created only to test this). 1. With last month's org-mode in emacs 24 I needed more than 5 minutes to open it, and then moving around the file was too slow to be comfortable (local editing was however acceptable). 2. With the current one, it's only 10 seconds loading time, local editing is still fast, and jumping around sections takes at most 2 seconds per move. So this change has made me stop worrying about files growing too fast, at least for many years. Thanks!
Re: [O] link interfering with brackets when abbreviated
Hi Nicolas, Nicolas Goaziou writes: > As I said, the "end of line" is not a structural unit. Implementing that > "feature", which, I must admit, I find cheesy, back will be fragile and > confusing. > > For example, white spaces after an object still belong to an > object. Well, this is counterintuitive. > So in the following case: > > [[http://orgmode.org]] [[http://duckduckgo.com]] > > using C-c C-o between the two links will open the first one, but there: > > [[http://orgmode.org]] and [[http://duckduckgo.com]] > > C-c C-o on the "and" will open the second one. This current behavior is surprising too here, and only predictable for users who know that whitespaces are part of the previous object -- i.e. nobody. > Also in the following example: > > [fn:1] This is some text [[http://orgmode.org]] > > C-c C-o on "some" currently triggers `org-footnote-action' since point > is in a footnote definition. Which is counterintuitive too! > But with the behaviour you describe, it would be hard to predict > whether it should move to the link or still open the footnote. Let me describe the behavior I favor: C-c C-o opens the link at point (i.e. "the link that the cursor is visibly on") or the next link on the same line. When on a headline and if there are several links on the same line, prompt the user for which one she wants to visit. I find it very simple and predictable. > There are many other examples. This "convenient feature" is > unpredictable and not worth implementing back (not counting the fact > that it wouldn't be totally trivial to do properly). Sorry, but the current behavior feels just too wrong. -- Bastien
Re: [O] link interfering with brackets when abbreviated
Hi Nicolas, "we" was short for "we, Org contributors", and it was a request for comment, so I'm glad you did. I understand your point very well: structural consistency favors ease of maintainance and evolutivity. The new export engine is a perfect example of this: without a clean parser, it would not exist. But this is also a perfect example of what I want to insist on: the benefit of relying on the parser has to be very clear. It is not something you can systematically and blindly taken for granted. For example, if we were to rely on the parser for fontification now, it would be certainly too slow, and the cost for the user would be too high. I know this rewrite is somewhere on the roadmap, and I know you will consider it only when the cost of the slowdown will not be too high -- so the trade-off strategy I was describing is something I guess we (as in "you and me") agree on. Thanks, -- Bastien
Re: [O] export ICal without evaluate code block
Hello, Simon Thum writes: > I have some worries here; Why is it so hard to avoid > evaluation/modification in org files during export? I don't think it is. There is a single variable to switch in order to control this: `org-export-babel-evaluate'. Do you think that it doesn't behave as expected? > I use -batch, I would have tought that was enough, but if I'm getting > your answer below right, then setting those 2 parameters is not enough > either, because some backends fiddle with them? > > I have searched the docs but did not find anything about backends > overriding these settings. Besides `icalendar' in a very specific configuration (when exporting a calendar, not a single document) I don't think any back-end overwrites the previous variable. Regards, -- Nicolas Goaziou
Re: [O] link interfering with brackets when abbreviated
Bastien writes: > Here are the reasons why we *want* to rewrite some functions using > org-element: I don't know who "we" is. Apparently, I'm not in. > - *bug fixing*: the rewrite fixes bugs. > > - *speed*: the rewrite provides a faster implementation; > > - *predictability*: the rewrite provides a more predictable >implementation; > > - *completeness*: the rewrite covers more use-cases than the > previous /ad hoc/ implementation. > > Now here are the reasons why we *don't want* to use org-element: > > - *high ceiling*: if the rewrite is less readable for potential > developers. > > - *complexity*: if the rewritten version is more complex. > > - *rigidity*: if the rewritten version adds unwanted constraints. > > Of course, the decision is always a trade-off. > > I'm particularily sensitive to the "high ceiling" point above: we > don't want all contributors to learn about Org elements before they > can submit a patch -- of course, many will do, and we can encourage > them to do so, but let's not close too many doors. > > IOW, even though org-element.el is great (and I hope my comments above > will not be taken as criticism), "rewriting using org-element" is not > a goal /per se/, just one great possibility to use when needed. I think at least one of us is missing the point. I do not "rewrite using Elements" for any of the reasons above. But before I explain my reasons, I will comment "we"'s a bit. I cannot talk about bug fixing and completeness as it depends on the function rewritten. Though, don't hold your breath, implementation with Elements will /always/ be slower than the current one. I'm working on the cache to make that fact bearable, but I don't possess pixie dust. Also, I'm pretty sure it will never be less rigid. A parser is inherently very rigid. But this will sure make it more predictable. Moreover, learning about "org-element.el" is not that hard. There are 4 major functions: `org-element-at-point', `org-element-context', `org-element-property' and `org-element-type'. Of course, it can help to also know about properties attached to each element type. That's documented in Worg and pretty explicit in "org-element.el". Anyway, back to my reasons to "rewrite using Elements". Org consists of mostly (but not totally) independent parts, each one implementing its own Org parser, similar to the others, but sometimes slightly different. This is, to say the least, highly inefficient. It is also a potential source of bugs. Worse, it can impede further improvements. Indeed, I doubt that anyone knows Org's full code base. So any slight change to syntax could break some unknown parts of Org. Therefore, basically no structural improvement can happen today without tremendous efforts and pain (for the very same reasons, no new export back-end could be created yesterday). A function rewritten using Elements shares the same knowledge about Org syntax with other rewritten functions. If we improve Elements, all of them benefit from the improvement. If we modify it, all of them get the modification. I'm exaggerating it a bit, but I'm sure you get the idea. It is no panacea, but IMO, Org will be a better place when all of its parts agree on a common, unambiguous, syntax. So, in a nutshell, rewriting using org-element is almost a goal /per se/. It comes with a price, which is that a re-implementation is not a perfect copy of the original function, but the reward is higher. If "we" disagree with that, then it would nice be if "we" could let me know. Better late than sorry, I guess. Regards, -- Nicolas Goaziou
Re: [O] export ICal without evaluate code block
Nicolas, I recently had a similar problem, though in my case the iClaendar export wasn't even reached because emacs started asking in other exports that came before. I have some worries here; Why is it so hard to avoid evaluation/modification in org files during export? I use -batch, I would have tought that was enough, but if I'm getting your answer below right, then setting those 2 parameters is not enough either, because some backends fiddle with them? I have searched the docs but did not find anything about backends overriding these settings. Enlightenment is appreciated. Cheers, Simon On 02/26/2014 03:17 PM, Nicolas Goaziou wrote: Hello, OSiUX writes: Calendar can be exported without evaluating babel code blocks? I try setting in .emacs: (setq org-confirm-babel-evaluate nil) (setq org-export-babel-evaluate nil) but always evaluate when exports iCalendar :-( You could use something like this: (defun my-toggle-off-babel (backend) (when (org-export-derived-backend-p backend 'icalendar) (org-set-local 'org-confirm-babel-evaluate nil) (org-set-local 'org-export-babel-evaluate nil))) (add-hook org-export-before-processing-hook #'my-toggle-off-babel) Regards,
Re: [O] export ICal without evaluate code block
El mié, 26 feb 2014, Nicolas Goaziou decía: > OSiUX writes: > > > El mié, 26 feb 2014, Nicolas Goaziou decía: > > >> You could use something like this: > >> > >> (defun my-toggle-off-babel (backend) > >> (when (org-export-derived-backend-p backend 'icalendar) > >> (org-set-local 'org-confirm-babel-evaluate nil) > >> (org-set-local 'org-export-babel-evaluate nil))) > >> > >> (add-hook org-export-before-processing-hook #'my-toggle-off-babel) > > > > Thanks Nicolas, your workaround don't work for me: > > > > Debugger entered--Lisp error: > > (void-variable org-export-before-processing-hook) > > (add-hook org-export-before-processing-hook (function > > my-toggle-off-babel)) > > I forgot a quote: > > (add-hook 'org-export-before-processing-hook #'my-toggle-off-babel)) oops! OK thanks, now it works great! > > Looking the source I found this commit: > > > > commit 69ebb265be118ea1a37afb9603c4582d25d33d09 > > Author: Bastien Guerry > > Date: Wed Apr 10 18:40:47 2013 +0200 > > > > ox-icalendar.el (org-icalendar-export-current-agenda): Do not > > evaluate babel co$ > > > > * ox-icalendar.el (org-icalendar-export-current-agenda): Do > > not evaluate babel code blocks. > > > > Thanks to Nicolas for directions about this. > > > > should work with the export current file option > > but does not work :-( > > No, this patch is about calling icalendar exporter on the agenda. > I guess you are calling it on an Org buffer, which is different. No problem, I use batch mode export: ORG -> ICS -> REM -> TXT https://github.com/osiris/org-bash-utils/blob/master/agenda-ascii > Regards, thank you! -- :: Osiris Alejandro Gomez (OSiUX) os...@osiux.com.ar DC44 95D2 0D5D D544 FC1A F00F B308 A671 9237 D36C http://www.osiux.com.ar http://www.altermundi.net signature.asc Description: Digital signature
Re: [O] Org release 8.2.5g (minor release from maint)
Achim Gratz writes: > Splicing seems slightly more elegant than list construction, but > pre-info needs to be preserved. Eric, please review the attached patch, > I'm not certain about the current test coverage in that area. I see that this bug remains unfixed. Eric, could you please have a look? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] link interfering with brackets when abbreviated
Hello, Bastien writes: > Count me in -- this is a regression that needs to be fixed. > > Nicolas, any stronger objection than the one your already > expressed? As I said, the "end of line" is not a structural unit. Implementing that "feature", which, I must admit, I find cheesy, back will be fragile and confusing. For example, white spaces after an object still belong to an object. So in the following case: [[http://orgmode.org]] [[http://duckduckgo.com]] using C-c C-o between the two links will open the first one, but there: [[http://orgmode.org]] and [[http://duckduckgo.com]] C-c C-o on the "and" will open the second one. Also in the following example: [fn:1] This is some text [[http://orgmode.org]] C-c C-o on "some" currently triggers `org-footnote-action' since point is in a footnote definition. But with the behaviour you describe, it would be hard to predict whether it should move to the link or still open the footnote. There are many other examples. This "convenient feature" is unpredictable and not worth implementing back (not counting the fact that it wouldn't be totally trivial to do properly). Regards, -- Nicolas Goaziou
Re: [O] link interfering with brackets when abbreviated
Hi Michael and Nicolas, Michael Brand writes: > And once again thank you for your work in reimplementing more and more > by using org-element. A quick note on this. Here are the reasons why we *want* to rewrite some functions using org-element: - *bug fixing*: the rewrite fixes bugs. - *speed*: the rewrite provides a faster implementation; - *predictability*: the rewrite provides a more predictable implementation; - *completeness*: the rewrite covers more use-cases than the previous /ad hoc/ implementation. Now here are the reasons why we *don't want* to use org-element: - *high ceiling*: if the rewrite is less readable for potential developers. - *complexity*: if the rewritten version is more complex. - *rigidity*: if the rewritten version adds unwanted constraints. Of course, the decision is always a trade-off. I'm particularily sensitive to the "high ceiling" point above: we don't want all contributors to learn about Org elements before they can submit a patch -- of course, many will do, and we can encourage them to do so, but let's not close too many doors. IOW, even though org-element.el is great (and I hope my comments above will not be taken as criticism), "rewriting using org-element" is not a goal /per se/, just one great possibility to use when needed. -- Bastien
Re: [O] link interfering with brackets when abbreviated
Hi Michael, Michael Brand writes: > I expect some users to go through the same surprise than me. Maybe > that there will be enough voices to get the searching on the same line > for "C-c C-o" (org-open-at-point) back. Count me in -- this is a regression that needs to be fixed. Nicolas, any stronger objection than the one your already expressed? -- Bastien
Re: [O] link interfering with brackets when abbreviated
Hi Nicolas On Wed, Feb 26, 2014 at 5:41 PM, Nicolas Goaziou wrote: > > Michael Brand writes: > >> What is the benefit of removing the search on the same line? > > `org-element-context' returns the context under point, not on the other > side of the line. Your are on a link, C-c C-o opens it, otherwise, it > doesn't. I find it very predictable. > > The "feature" you are missing probably made sense in the previous > implementation, since it already searched forward for a link, but it > would be confusing (and more costly) in the new one. I expect some users to go through the same surprise than me. Maybe that there will be enough voices to get the searching on the same line for "C-c C-o" (org-open-at-point) back. Michael
Re: [O] export ICal without evaluate code block
OSiUX writes: > El mié, 26 feb 2014, Nicolas Goaziou decía: >> You could use something like this: >> >> (defun my-toggle-off-babel (backend) >> (when (org-export-derived-backend-p backend 'icalendar) >> (org-set-local 'org-confirm-babel-evaluate nil) >> (org-set-local 'org-export-babel-evaluate nil))) >> >> (add-hook org-export-before-processing-hook #'my-toggle-off-babel) > > Thanks Nicolas, your workaround don't work for me: > > Debugger entered--Lisp error: > (void-variable org-export-before-processing-hook) > (add-hook org-export-before-processing-hook (function > my-toggle-off-babel)) I forgot a quote: (add-hook 'org-export-before-processing-hook #'my-toggle-off-babel)) > Looking the source I found this commit: > > commit 69ebb265be118ea1a37afb9603c4582d25d33d09 > Author: Bastien Guerry > Date: Wed Apr 10 18:40:47 2013 +0200 > > ox-icalendar.el (org-icalendar-export-current-agenda): Do not evaluate > babel co$ > > * ox-icalendar.el (org-icalendar-export-current-agenda): Do > not evaluate babel code blocks. > > Thanks to Nicolas for directions about this. > > should work with the export current file option > but does not work :-( No, this patch is about calling icalendar exporter on the agenda. I guess you are calling it on an Org buffer, which is different. Regards, -- Nicolas Goaziou
Re: [O] link interfering with brackets when abbreviated
Hello, Michael Brand writes: > What is the benefit of removing the search on the same line? `org-element-context' returns the context under point, not on the other side of the line. Your are on a link, C-c C-o opens it, otherwise, it doesn't. I find it very predictable. The "feature" you are missing probably made sense in the previous implementation, since it already searched forward for a link, but it would be confusing (and more costly) in the new one. Regards, -- Nicolas Goaziou
Re: [O] List of figures
Aloha Nicolas, Nicolas Goaziou writes: > Hello, > > t...@tsdye.com (Thomas S. Dye) writes: > >> I can imagine that a list of figures is a difficult problem in some >> other back-ends. However, its absence in LaTeX export seems unusual. > > Org doesn't cover all LaTeX facilities. There are #+LATEX: > and #+BEGIN_LATEX...#+END_LATEX to fill the gap. > >> Would it make sense to have this work as expected for LaTeX export (and >> perhaps other back-ends where it does make sense) > > We can start to discuss what a good implementation could be for major > back-ends. But implementing it for LaTeX only is, IMO, not worth the > trouble: > > #+toc: figures > > vs. > > #+latex: \listoffigures AFAICT the new exporter works flawlessly. I'm confident that it will let me produce LaTeX to any practical specification. My original query came about because I was trying to write Org markup and *not* drop down to LaTeX. In this context--Org as a lightweight markup language--the possibility of creating all but one of the "lists-of" with #+TOC: seems like the markup language core is missing a piece. I look forward to the discussion of implementations for the major back-ends. Let me know if I can help in any way. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] link interfering with brackets when abbreviated
Hi Nicolas On Wed, Feb 26, 2014 at 4:54 PM, Nicolas Goaziou wrote: > I don't understand. Using C-c C-o on "1" "2" or "3" will not open any > link since point is not on a link anyway. So you will consistently get > "No link found". Aha, now as I see that you removed the following from the docstring of org-open-at-point I start to get it: If there is no link at point, this function will search forward up to the end of the current line. Before I found it _very_ useful that after I navigated to the right line at last, I didn't have to navigate further within this line. That the position of point within a line with an Org list item matters for structure editing I can follow. But for org-open-at-point I do not yet understand this requirement. What is the benefit of removing the search on the same line? Michael
Re: [O] export ICal without evaluate code block
El mié, 26 feb 2014, Nicolas Goaziou decía: > Hello, > > OSiUX writes: > > > Calendar can be exported without evaluating > > babel code blocks? > > > > I try setting in .emacs: > > > > (setq org-confirm-babel-evaluate nil) > > (setq org-export-babel-evaluate nil) > > > > but always evaluate when exports iCalendar :-( > > You could use something like this: > > (defun my-toggle-off-babel (backend) > (when (org-export-derived-backend-p backend 'icalendar) > (org-set-local 'org-confirm-babel-evaluate nil) > (org-set-local 'org-export-babel-evaluate nil))) > > (add-hook org-export-before-processing-hook #'my-toggle-off-babel) Thanks Nicolas, your workaround don't work for me: Debugger entered--Lisp error: (void-variable org-export-before-processing-hook) (add-hook org-export-before-processing-hook (function my-toggle-off-babel)) Looking the source I found this commit: commit 69ebb265be118ea1a37afb9603c4582d25d33d09 Author: Bastien Guerry Date: Wed Apr 10 18:40:47 2013 +0200 ox-icalendar.el (org-icalendar-export-current-agenda): Do not evaluate babel co$ * ox-icalendar.el (org-icalendar-export-current-agenda): Do not evaluate babel code blocks. Thanks to Nicolas for directions about this. should work with the export current file option but does not work :-( -- :: Osiris Alejandro Gomez (OSiUX) os...@osiux.com.ar DC44 95D2 0D5D D544 FC1A F00F B308 A671 9237 D36C http://www.osiux.com.ar http://www.altermundi.net signature.asc Description: Digital signature
Re: [O] [ANN] Lazy cache synchronization
Nicolas Richard writes: > I'm sorry that this is only a "thank you" message (vs, e.g., actual work > from me in the directions you suggest), it certainly deserves more than > that, but I'd find it sad if it had no answer at all. I guess most people are like me: there is so much to thank Nicolas for that we don't know where to start. But you're right, that's a great structural achievement, so *thank* you Nicolas! -- Bastien
Re: [O] link interfering with brackets when abbreviated
Michael Brand writes: > With point exactly on all variants of "1", "2" and "3"? _On_ is also > important to see the difference of "1" and "2" vs. "3" for the old > issue in release_8.2.5h-645-g3f55b45, please check that too. I don't understand. Using C-c C-o on "1" "2" or "3" will not open any link since point is not on a link anyway. So you will consistently get "No link found". Regards, -- Nicolas Goaziou
[O] How can I continue my code listing in Beamer slides?
Hi everyone, I have a question about beamer export in org. I have some code to be put in my slides. The problem is that one slide (or one column block) does not have enough space for it. How can I split it into two slides or several column blocks? Please help me with it. etimecowboy
Re: [O] link interfering with brackets when abbreviated
Hi Nicolas On Wed, Feb 26, 2014 at 4:25 PM, Nicolas Goaziou wrote: > I do not get any error, i.e, every link is opened in the browser. With point exactly on all variants of "1", "2" and "3"? _On_ is also important to see the difference of "1" and "2" vs. "3" for the old issue in release_8.2.5h-645-g3f55b45, please check that too. > Did you refresh your local set-up with C-c C-c on the LINK keyword? Yes, also with C-c C-c. Anyway I used git checkout master && git pull && make cleanall uncompiled && \\ /x/arch/emacs/src/emacs -Q -L /x/git/org-mode/lisp /z/x.org with GNU Emacs 24.3.2 and now also 24.1.1 and 23.4.1. Michael
Re: [O] link interfering with brackets when abbreviated
Hello, Michael Brand writes: > The above old issue with "3" remains the same on > release_8.2.5h-645-g3f55b45. > > The recent regression is from release_8.2.5h-647-gfc9ce86 > > commit fc9ce86cfc1ecf7e86028027a12875a26500e774 > Author: Nicolas Goaziou > Date: Sun Feb 23 11:35:34 2014 +0100 > > Rewrite `org-open-at-point' using Elements > > and leads to the error "No link found", on all of "1", "2" and "3". With the following Org document: --8<---cut here---start->8--- #+LINK: link-abbreviation http://www.orgmode.org/# 1) [ ] [[http://www.orgmode.org/#docs]] 2) [[link-abbreviation:docs]] 3) [ ] [[link-abbreviation:docs]] 1 bla bla [ ] [[http://www.orgmode.org/#docs]] 2 bla bla [[link-abbreviation:docs]] 3 bla bla [ ] [[link-abbreviation:docs]] | 1 | [ ] | [[http://www.orgmode.org/#docs]] | | 2 | | [[link-abbreviation:docs]] | | 3 | [ ] | [[link-abbreviation:docs]] | --8<---cut here---end--->8--- I do not get any error, i.e, every link is opened in the browser. Did you refresh your local set-up with C-c C-c on the LINK keyword? Regards, -- Nicolas Goaziou
Re: [O] link interfering with brackets when abbreviated
Hi Nicolas There is a recent regression that I hope I can use to revive an old unanswered thread that, as it seems to me, is perfectly related. On Thu, Oct 3, 2013 at 2:11 PM, Michael Brand wrote: > Hi all > > The recent bug report below reminds me of a comparable situation with > a bug that I wanted to report at some time: > > > #+LINK: link-abbreviation http://www.orgmode.org/# > > 1) [ ] [[http://www.orgmode.org/#docs]] > 2) [[link-abbreviation:docs]] > 3) [ ] [[link-abbreviation:docs]] > > 1 bla bla [ ] [[http://www.orgmode.org/#docs]] > > 2 bla bla [[link-abbreviation:docs]] > > 3 bla bla [ ] [[link-abbreviation:docs]] > > | 1 | [ ] | [[http://www.orgmode.org/#docs]] | > | 2 | | [[link-abbreviation:docs]] | > | 3 | [ ] | [[link-abbreviation:docs]] | > > > C-c C-o with point on "1" or "2" opens the browser, on "3" I expect > the same but an error happens. > > Michael > > On Thu, Oct 3, 2013 at 12:56 PM, Christoph LANGE > wrote: > subject: C-c C-c doesn't tick check box when pressed on a hyperlink in a > list item >> this is a bug in Org 8.2 on Emacs 24.3. I can't use >> org-submit-bug-report right now (see previous mail), so let me try this way. >> >> I have a check list like this >> >> * [X] item >> * [ ] item >> >> and some of the items contain hyperlinks. When I am on one such >> hyperlink and press C-c C-c it doesn't tick the check box but says "C-c >> C-c can do nothing useful at this location". The above old issue with "3" remains the same on release_8.2.5h-645-g3f55b45. The recent regression is from release_8.2.5h-647-gfc9ce86 commit fc9ce86cfc1ecf7e86028027a12875a26500e774 Author: Nicolas Goaziou Date: Sun Feb 23 11:35:34 2014 +0100 Rewrite `org-open-at-point' using Elements and leads to the error "No link found", on all of "1", "2" and "3". And once again thank you for your work in reimplementing more and more by using org-element. Michael
Re: [O] export ICal without evaluate code block
Hello, OSiUX writes: > Calendar can be exported without evaluating > babel code blocks? > > I try setting in .emacs: > > (setq org-confirm-babel-evaluate nil) > (setq org-export-babel-evaluate nil) > > but always evaluate when exports iCalendar :-( You could use something like this: (defun my-toggle-off-babel (backend) (when (org-export-derived-backend-p backend 'icalendar) (org-set-local 'org-confirm-babel-evaluate nil) (org-set-local 'org-export-babel-evaluate nil))) (add-hook org-export-before-processing-hook #'my-toggle-off-babel) Regards, -- Nicolas Goaziou
Re: [O] LaTeX export: Handle hash symbol in footnote url links
Hello, Michael Bach writes: > Thanks for your answer. `\url` can handle hash symbols in its argument > without escaping alright - as can be expected. AFAICS, the problem lies > in the `\footnote` command. And yes, I was thinking of `ox-latex` > figuring out that the url is in a footnote and escape accordingly. > > I can see that the export engine should not and cannot cover all special > cases, but since links and footnotes are `first-class` org-mode > concepts, it would be nice to have them play along in this situation. > From a typographic point of view, I figured url links in footnotes are > not that unusual. This needs to be properly defined. Where protecting characters in verbatim parts of the buffer should happen? Within footnotes only? In every verbatim part? And on which characters? Regards, -- Nicolas Goaziou
Re: [O] Bug (or at least a trap) in exporting #+begin_src blocks
Hello, Giovanni Moretti writes: > Could I ask that an error message be generated for this? The problem is that is a valid Org syntax (though different than the one you expect), so it isn't an error /per se/. So, the parser will not generate an error for this. > While not strictly a bug, it's an insidious trap given that the > in-buffer expansion (C-c C-c) runs and inserts the results as > expected. I hope that, one day, Babel will rely on the same parser as the export framework. Until then, (minor) discrepancies are to be expected. Regards, -- Nicolas Goaziou
Re: [O] [ANN] Lazy cache synchronization
Hi Nicolas On Wed, Feb 26, 2014 at 2:58 PM, Nicolas Goaziou wrote: > It should be fixed. Thank you for reporting it. Yes, thank you. Michael
Re: [O] [ANN] Lazy cache synchronization
Hello, Michael Brand writes: > The related commit release_8.2.5h-642-geed0500 > > commit eed0500913a3534a32abfd5864cf674d9d0cdf64 > Author: Nicolas Goaziou > Date: Fri Jan 31 01:14:44 2014 +0100 > > org-element: Implement lazy cache synchronization > > on master is a regression for find-file of an Org file containing the > header > > * Definition of <<>> and <<>> It should be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] List of figures
Hello, t...@tsdye.com (Thomas S. Dye) writes: > I can imagine that a list of figures is a difficult problem in some > other back-ends. However, its absence in LaTeX export seems unusual. Org doesn't cover all LaTeX facilities. There are #+LATEX: and #+BEGIN_LATEX...#+END_LATEX to fill the gap. > Would it make sense to have this work as expected for LaTeX export (and > perhaps other back-ends where it does make sense) We can start to discuss what a good implementation could be for major back-ends. But implementing it for LaTeX only is, IMO, not worth the trouble: #+toc: figures vs. #+latex: \listoffigures > and have other back-ends insert a comment? Comments do not always make sense (e.g. ascii). Regards, -- Nicolas Goaziou
Re: [O] [ANN] Lazy cache synchronization
Nicolas Goaziou writes: > Now, synchronization happens lazily, which means the cache is only > updated when and where needed, or during idle time. Therefore the cache > mechanism scales a lot better. This seems to be an awesome news ! I can hardly believe you manage to find the time to do this. I'm sorry that this is only a "thank you" message (vs, e.g., actual work from me in the directions you suggest), it certainly deserves more than that, but I'd find it sad if it had no answer at all. -- Nico.
Re: [O] org-mode/elpa setup
Awesome! Thanks, this is exactly what I was looking for! John --- John Kitchin Associate Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu On Wed, Feb 26, 2014 at 3:12 AM, Achim Gratz wrote: > John Kitchin andrew.cmu.edu> writes: > > I was wondering if there is any documentation somewhere on > > how the orgmode elpa repo is setup. > > Have a look in mk/server.mk, which you can include from local.mk if you > want > to roll your own ELPA tar balls. > > Regards, > Achim. > > > > >
Re: [O] [ANN] Lazy cache synchronization
Hi Nicolas On Thu, Feb 20, 2014 at 11:08 PM, Nicolas Goaziou wrote: > I just pushed an update for parser cache. The related commit release_8.2.5h-642-geed0500 commit eed0500913a3534a32abfd5864cf674d9d0cdf64 Author: Nicolas Goaziou Date: Fri Jan 31 01:14:44 2014 +0100 org-element: Implement lazy cache synchronization on master is a regression for find-file of an Org file containing the header * Definition of <<>> and <<>> Michael Debugger entered--Lisp error: (wrong-type-argument hash-table-p nil) gethash((headline (:raw-value "Summary of <<>> and <<>>" :begin 1 :end 38 :pre-blank 0 :contents-begin nil :contents-end nil :level 1 :priority nil :tags nil :todo-keyword nil :todo-type nil :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil :CATEGORY nil :title "Summary of <<>> and <<>>")) nil) (and (org-element--cache-active-p) (gethash element org-element--cache-objects)) (let* ((restriction (org-element-restriction type)) (parent element) (candidates (quote initial)) (cache (and (org-element--cache-active-p) (gethash element org-element--cache-objects))) objects-data next) (prog1 (catch (quote exit) (while t (if next nil (let ((data ...)) (if data (setq candidates ...) (setq cache ... (if (or next (eq (quote initial) candidates)) (progn (setq candidates (org-element--get-next-object-candidates restriction candidates)) (setcar (cdr objects-data) candidates))) (let ((closest (and candidates ...))) (if (or (not closest) (> ... origin)) (catch (quote found) (progn ...)) (goto-char (cdr closest)) (setq next (funcall ...)) (let* (...) (setcdr ... ... (let ((cbeg (org-element-property :contents-begin next)) (cend (org-element-property :contents-end next)) (obj-end (org-element-property :end next))) (cond ((<= obj-end origin) (goto-char obj-end)) ((or ... ... ...) (org-element-put-property next :parent parent) (throw ... next)) (t (goto-char cbeg) (narrow-to-region ... cend) (org-element-put-property next :parent parent) (setq parent next restriction ... next nil objects-data nil candidates ...)) (org-element--cache-put element cache))) (let* ((origin (point)) (element (or element (org-element-at-point))) (type (org-element-type element))) (cond ((let ((post (org-element-property :post-affiliated element))) (and post (< origin post))) (beginning-of-line) (let ((case-fold-search t)) (looking-at org-element--affiliated-re)) (cond ((not (member-ignore-case (match-string 1) org-element-parsed-keywords)) (throw (quote objects-forbidden) element)) ((< (match-end 0) origin) (narrow-to-region (match-end 0) (line-end-position))) ((and (match-beginning 2) (>= origin (match-beginning 2)) (< origin (match-end 2))) (narrow-to-region (match-beginning 2) (match-end 2))) (t (throw (quote objects-forbidden) element))) (setq type (quote keyword))) ((eq type (quote item)) (let ((tag (org-element-property :tag element))) (if (not tag) (throw (quote objects-forbidden) element) (beginning-of-line) (search-forward tag (line-end-position)) (goto-char (match-beginning 0)) (if (and (>= origin ...) (< origin ...)) (narrow-to-region (point) (match-end 0)) (throw (quote objects-forbidden) element) ((memq type (quote (headline inlinetask))) (goto-char (org-element-property :begin element)) (skip-chars-forward "* ") (if (and (>= origin (point)) (< origin (line-end-position))) (narrow-to-region (point) (line-end-position)) (throw (quote objects-forbidden) element))) ((memq type (quote (paragraph table-row verse-block))) (let ((cbeg (org-element-property :contents-begin element)) (cend (org-element-property :contents-end element))) (if (and cbeg cend (>= origin cbeg) (or (< origin cend) (and ... ...))) (narrow-to-region cbeg cend) (throw (quote objects-forbidden) element ((eq type (quote keyword)) (if (not (member (org-element-property :key element) org-element-document-properties)) (throw (quote objects-forbidden) element) (beginning-of-line) (search-forward ":") (if (and (>= origin (point)) (< origin (line-end-position))) (narrow-to-region (point) (line-end-position)) (throw (quote objects-forbidden) element ((eq type (quote planning)) (progn (let ((--dolist-tail-- (quote ...)) p) (while --dolist-tail-- (setq p (car --dolist-tail--)) (let (...) (if ... ...)) (setq --dolist-tail-- (cdr --dolist-tail--) (throw (quote objects-forbidden) element)) (t (throw (quote objects-forbidden) element))) (goto-char (point-min)) (let* ((restriction (org-element-restriction type)) (parent element) (candidates (quote initial)) (cache (and (org-element--cache-active-p) (gethash element org-element--cache-objects))) objects-data next) (prog1 (catch (quote exit) (while t (if next nil (let (...) (if data ... ...))) (if (or next (eq ... candidates)) (progn (setq candidates ...) (setcar ... candidates))) (let ((closest ...)) (if (or ... ...) (catch ... ...) (goto-char ...) (setq next ...) (let* ... ...))) (let ((cbeg ...) (cend ...)
Re: [O] Include on file open?
On Wed, Feb 26, 2014 at 02:07:22PM +0800, Eric Abrahamsen wrote: > > I think org-toc in the contrib/lisp directory is meant to do just this, > automatically. I haven't tried it, though... > Ah! Excellent! Thanks very much! -pd -- Peter Davis The Tech Curmudgeon www.techcurmudgeon.com
Re: [O] Namespace problem org-mode / Clojure
On Tue, 2014-02-25 at 06:20 -0500, Soapy Smith wrote: > I will add this issue to the list of TODOs for Clojure code blocks. > > One thing I can do quickly is see if the problem exists in version 7.9 > org with nrepl (prior to CIDER). I have a machine which still has the > old configuration. I will try later today and report. > > Regards, > Greg > (alias Soapy Smith) The namespaces worked perfectly on the older machine with org 7.9 and nrepl. The problem is apparently isolated to the newest configuration using CIDER with org 8. Regards, Greg
Re: [O] Bug: open date in SCHEDULED: lines [8.2.5h (release_8.2.5h-662-ge4a955 @ /home/youngfrog/sourcetrees/org-mode/lisp/)]
Le 25/02/2014 17:52, Nicolas Goaziou a écrit :
> Nicolas Richard writes:
>> Starting with fc9ce86cfc1ecf7e86028027a12875a26500e774, hitting C-c C-o
>> on a timestamp in a SCHEDULED: line doesn't work anymore ("No link
>> found"). I expected it to open the agenda like it does on other links.
>
> This should be fixed. Thank you for reporting it.
It indeed is, thanks.
--
N.R.
[O] Exporter prints strange and unwanted underscore
Hi List, [This was posted on the Emacs help mailing list too with a different subject - before I figured out it might rather be an Org-mode problem.] This is what I see in a temporary Emacs buffer when I'm in Emacs(client) and let my Org-mode exporter produce a nested list as output that will be sent to PicoLisp: #+begin_src picolisp (section (parent-id 8) "[2013-06-28 Fr 11:01]^J") ^J(headline (org-elem-id 12 ...) ) #+end_src but when I go to the other side and call Emacsclient from PicoLisp and redirect what is sent into a file, it looks like this: #+begin_src picolisp (section (parent-id 8) \"[2013-06-28 Fr 11:01]^J\")_^J (headline (org-elem-id 12 ...) ) #+end_src thus a strange and unwanted underscore (_) is printed before the ^J. This is how the respective snippet looks in the original Org file: ,- | * header 2:TASK: | [2013-06-28 Fr 11:01] | ** subheader 1 `- It looks like a problem with the Org-mode exporter who produces this nested list from an Org-mode file/buffer. So the questions are probably: 1. what invisible character behind the inactive timestamp might be transformed into an _ by the exporter? 2. why does the exporter behave differently when called from Emacs on an open Org-mode buffer (correct output in the temporary buffer) then when called from an external program (incorrect output with strange underscore in the file where output was redirected)? Any hints are welcome. -- cheers, Thorsten
[O] [bug] Fontification of bold and italics
Hello, With recent Org, sentences such as [1]: --8<---cut here---start->8--- Explanation *answers the question "why?"*: show *why* the facts make sense. Explanation *makes people /care/*, so they are more motivated about learning more. "Why would I want to do /that/?" --8<---cut here---end--->8--- are badly fontified. Tested with a minimal Emacs file. See http://screencast.com/t/Qcx60vU3. Best regards, Seb [1] From the excellent book "The art of explanation" (Lee LeFever). -- Sebastien Vauban
[O] BUG org-babel-goto-named-src-block with indented block
Hi all, there seems to be a bug, where org-babel-goto-named-src-block does not find an indented source block. Here is an example: --8<---cut here---start->8--- * Test org-babel-goto-named-src-block Try org-babel-goto-named-src-block (C-c C-v g) with point on the following line. (This works for me.) #+call: block1(20) Try org-babel-goto-named-src-block (C-c C-v g) with point on the following line. (This does not work for me.) #+call: block2(20) ** The first block *without* indentation #+name: block1 #+header: :var end=10 #+begin_src R 1:end #+end_src ** The second block *with* indentation #+name: block2 #+header: :var end=11 #+begin_src R 2:end #+end_src --8<---cut here---end--->8--- Regards, Andreas
[O] org-table can't narrow
Hi, In the following org-file #+STARTUP: align | <10> | <4>| | h1 | h2 | |+| | text1 | [[http://orgmode.org][1-html]], [[http://orgmode.org/org.html][2-html]] | | text2 | fish | Is it a feature that the second column doesn't narrow? I don't recognize it as a feature from http://orgmode.org/org.html#Column-width-and-alignment On the other hand it could be a technical limitation. Thanks in advance, Rasmus -- . . . It begins of course with The Internet. A Net of Peers.
Re: [O] org-mode/elpa setup
John Kitchin andrew.cmu.edu> writes: > I was wondering if there is any documentation somewhere on > how the orgmode elpa repo is setup. Have a look in mk/server.mk, which you can include from local.mk if you want to roll your own ELPA tar balls. Regards, Achim.
