Re: [O] suggestion: M-m should move point to first word on line
Hi Eric, thanks for testing. Eric S Fraga writes: > this seems to cause a problem with org-ctrl-c-minus when trying to cycle > a bullet point past +. That is, it works if the bullet is - so you can > cycle to the next which is + but you cannot cycle past that. Attached patch (against master) fixes this problem. I'm not sure I'm in favor of this change, though, I expect it to cause other problems and the benefit looks small for now. Do you see other reasons than M-m where stars as whitespace chars are useful? What about *markup*? Thanks, >From a41bc3569e6812ce0c35e50abfc91590a47919c6 Mon Sep 17 00:00:00 2001 From: Bastien Guerry Date: Tue, 12 Feb 2013 08:30:14 +0100 Subject: [PATCH] org.el (org-mode): Set ?* to be syntactically a whitespace character * org-list.el (org-list-bullet-string): Don't skip all whitespace characters, skip whitespace and tab explicitely. * org.el (org-mode): Set ?* to be syntactically a whitespace character. --- lisp/org-list.el | 4 ++-- lisp/org.el | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index d86746f..e4d6d6d 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -1081,8 +1081,8 @@ It determines the number of whitespaces to append by looking at org-list-two-spaces-after-bullet-regexp bullet)) " " " "))) - (string-match "\\S-+\\([ \t]*\\)" bullet) - (replace-match spaces nil nil bullet 1 + (if (string-match "[^ \t]+\\([ \t]*\\)" bullet) + (replace-match spaces nil nil bullet 1) (defun org-list-swap-items (beg-A beg-B struct) "Swap item starting at BEG-A with item starting at BEG-B in STRUCT. diff --git a/lisp/org.el b/lisp/org.el index 461cdf0..a58c10b 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5173,6 +5173,7 @@ The following commands are available: (org-set-tag-faces 'org-tag-faces org-tag-faces)) ;; Calc embedded (org-set-local 'calc-embedded-open-mode "# ") + (modify-syntax-entry ?* " ") (modify-syntax-entry ?@ "w") (modify-syntax-entry ?\" "\"") (if org-startup-truncated (setq truncate-lines t)) -- 1.8.1.2 -- Bastien
Re: [O] Problem with org-html-format-latex
Vincent Beffara writes: >> > so simply testing >> > on the value of processing-type would work better, maybe? >> >> Yes, should be okay now, let me know! > > Nope, exactly the same. cache-relpath and cache-dir are not allowed to be > nil. Meaning that if processing-type is 'mathjax they should be set to > _some_ string anyway (the contents will be ignored eventually, but far down > the line unfortunately ...) Something like instead of your 'let' line > works: > > (let ((cache-relpath "") (cache-dir "") bfn) Mhh... okay. Now should be good. Thanks for your patience. -- Bastien
Re: [O] OT, but not really: todays XKCD
Jambunathan K writes: > A targeted donation (for individual work or hosting the servers) is much > better than an umbrella donation to Orgmode or Bastien. FWIW I agree. Any effective proposal against the website is welcome: ~$ git clone git://orgmode.org/orgweb.git Thanks, -- Bastien
Re: [O] suggestion: M-m should move point to first word on line
Bastien writes: [...] > Not to override `M-m' but perhaps to define "*" as a syntactic > whitespace character. > > Patch attached -- use with caution. I tested it a bit and it seems > to work, but not all tests pass and there may be side-effects that I > could not observe. Bastien, this seems to cause a problem with org-ctrl-c-minus when trying to cycle a bullet point past +. That is, it works if the bullet is - so you can cycle to the next which is + but you cannot cycle past that. I've tried this batch with org up to date a few minutes ago (ignore my signature info below as this emacs is running a slightly older org). Emacs was started with -Q. Debug trace: , | Debugger entered--Lisp error: (args-out-of-range 85 88) | replace-match(" " nil nil "*" 1) | org-cycle-list-bullet(nil) | call-interactively(org-cycle-list-bullet) | org-ctrl-c-minus() | call-interactively(org-ctrl-c-minus nil nil) ` Point was at column 0 of the first item in the attached minimal org file. I hope that's enough info... Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-975-g1eccd2 #+TITLE: examplebug.org #+AUTHOR:Eric S Fraga * cycling list bullet points + the first item + the second item + and the third and last item
Re: [O] OT, but not really: todays XKCD
Eric S Fraga writes: > Jambunathan K writes: > >> Why are you fudging with Mail Followup headers? Please don't >> underestimate the confusion it creates for others. > > I believe that most people expect responses to a mailing list email to > be directed to that list. Pray explain why Carsten appears in the followup post and you yourself don't figure in it. When I send a wide reply - S W in (gnus) - my response would have been sent "To" to Carsten. Precisely this is what I see in my Gnus buffer. , Reply buffer | To: "Dominik, Carsten" | Cc: "emacs-orgmode@gnu.org List" | Subject: Re: OT, but not really: todays XKCD | Gcc: nnfolder+archive:sent.2013-02 | From: Jambunathan K ` , Article buffer | Mail-Followup-To: Jambunathan K , "Dominik, Carsten" | , "emacs-orgmode@gnu.org List" | ` > I am sorry you have found this confusing. I will continue to be confused, unless an explanation is in order. I have noticed this consistently with your mails in the past. --
Re: [O] New exporter macro question
Hello Nicolas, thanks for your reply. I now remember this point of downgrading the macros and replacing complex macro calls with babel code. Thanks also for the easy work-around. - Carsten On 11.2.2013, at 22:37, Nicolas Goaziou wrote: > Hello, > > Carsten Dominik writes: > >> I am porting my websites to the new exporter, finally. Much is very smooth. >> I do have a problem with macros: >> >> >> * Macro definition >> >> >> #+MACRO: thumbright #+ATTR_HTML: style="float:right;width:$1;margin:0px >> 20px 0px 20px;" \n [[./Content/$2/thumb.jpg]] >> >> >> >> * Macro call >> >> {{{thumbright(300px,Wiskunde)}}} >> >> >> >> >> * This used to expand to >> >> > style="float:right;width:300px;margin:0px 20px 0px 20px;" >> alt="./Content/Wiskunde/thumb.jpg" /> >> >> >> * But now it expands to nothing >> I am sure I am missing something basic. Thanks! > > Macros have been downgraded a bit, as there was some overlapping with > Babel functionalities. In particular, they are meant to replace objects, > not elements, which means they cannot contain newline characters > anymore. > > You can use a Babel block to generate the Org code you want. You can > also try the following macro, which will generate the HTML code you > want: > > #+MACRO: thumbright @@html: style="float:right;width:$1;margin:0px 20px 0px 20px;" > alt="./Content/$2/thumb.jpg" />@@ > > > Regards, > > -- > Nicolas Goaziou
Re: [O] OT, but not really: todays XKCD
Jambunathan K writes: > Why are you fudging with Mail Followup headers? Please don't > underestimate the confusion it creates for others. I believe that most people expect responses to a mailing list email to be directed to that list. I am sorry you have found this confusing. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-975-g1eccd2
Re: [O] format of the ID property in the new HTML exporter
Daniel Clemente writes: > Hi, > in ox-html.el there's a line with an assert (the only one): > > (assert (org-uuidgen-p path)) > > > 1. I have some IDs like "o5y98600aze0" which don't conform to that uuidgen > format; they were created by early versions of org. Should only UUIDs be > accepted as ID? > 2. I think the ID should be editable by hand to what you like, as long as > they are unique. If you don't need to export it you don't need a CUSTOM_ID, > and having both ID and CUSTOM_ID is not the simplest way. > > So I think that assert is too strict. My short IDs seem as good as the long > UUIDs. There is ID and then there is CUSTOM_ID. IIUC/IIRC, ID is a uuid and CUSTOM_ID can be whatever. Any reason why you cannot use CUSTOM_IDs here? --
Re: [O] [ANN] outorg.el -- reverse Org-Babel
Thorsten Jolitz writes: > [about the nearly coincident publication of *outorg* and *poporg*] > What a bad luck ... ;( Oh, I'm not much into authorship wars, you know, as long as the need gets covered. Free time being a scarce resource (for me at least!), I prefer when we can all make the best use of it. Keep happy! François
Re: [O] org-bullets extension
François Pinard writes: > François Pinard writes: > >> Bastien writes: > >>> org-bullets.el is in the contrib/ directory. > >> Let me try to describe the problem. [...] > > Hmph! My description was not accurate, as I can now observe. Here is a > correction. Instead of: > >> The header gets opened, with all items visible, including the one just >> inserted. However, for that last item, this one that just got >> inserted, the bullet of the following header and header text is >> visually concatenated at the end of that item. Typing C-l >> (recenter-top-bottom) repairs the display: the bullet and its text >> visually jump on the next line, where they belong. > > I should have written: > >The header gets opened, with all items visible, *except* the one just >inserted. For the *previous to last* item, that is, *the last item >which is visible*, the bullet of the following header and header text >is visually concatenated at the end of that item. Typing C-l >(recenter-top-bottom) repairs the display: the *last inserted item >reappears*, and the bullet and its text visually jump on the next >line, where they belong. A screenshot is worth a 1000 words. Remember to CC the author. The author is keen to hear feedbacks and will act on it promptly. > Sorry for my prior lack of precision. > > François > > --
Re: [O] org-bullets extension
François Pinard writes: > Bastien writes: >> org-bullets.el is in the contrib/ directory. > Let me try to describe the problem. [...] Hmph! My description was not accurate, as I can now observe. Here is a correction. Instead of: > The header gets opened, with all items visible, including the one just > inserted. However, for that last item, this one that just got > inserted, the bullet of the following header and header text is > visually concatenated at the end of that item. Typing C-l > (recenter-top-bottom) repairs the display: the bullet and its text > visually jump on the next line, where they belong. I should have written: The header gets opened, with all items visible, *except* the one just inserted. For the *previous to last* item, that is, *the last item which is visible*, the bullet of the following header and header text is visually concatenated at the end of that item. Typing C-l (recenter-top-bottom) repairs the display: the *last inserted item reappears*, and the bullet and its text visually jump on the next line, where they belong. Sorry for my prior lack of precision. François
Re: [O] Bug: org-insert-heading-respect-content inserts at the wrong level if target heading is invisible [7.9.2 (release_7.9.2-883-g6fb36e.dirty @ /home/dlm/share/org-mode.git/lisp/)]
On Feb 12, 2013 1:31 AM, "Bastien" wrote: > > Hi James, > > James Harkins writes: > > > I'm resending the issue that I reported the other day, now with a > > MCE. > > Sorry for the delay on this -- and thanks for the detailed reports. > > I tried not to get lost in the details actually... so I ended up using > the attached fix. It works here, i.e. C-u C-RET inserts a new heading > at the right place, but I'm not using org-mobile.el so I'm not 100% > sure if it works for you. > > Can you test and confirm? I can, in about a week. I'm traveling, without my laptop (first time in years I've left it at home - phone and tablet only for this trip). I'm creating new entries in MobileOrg on the road. When I get home, I'll apply the patch and see what happens. One concern: When you tested with C-u C-RET, was the point on a hidden headline? The problem only occurs if the current heading is folded up underneath a parent heading. AFAIK cursor movement in org-mode ensures that the point is never on invisible text, which is why I wrote a short lisp function to demonstrate. It seems to me the issue reproduces only when calling org-insert-heading non-interactively, then, so I wanted to check if your test reproduces the problem without the patch. hjh
Re: [O] OT, but not really: todays XKCD
Why are you fudging with Mail Followup headers? Please don't underestimate the confusion it creates for others. --
Re: [O] [ANN] outorg.el -- reverse Org-Babel
François Pinard writes: Hi, Francois, > Just from reading your description, "outorg" seems strangely similar to > "poporg" (https://github.com/pinard/poporg), which I announced on this > list maybe two weeks ago. I would presume you missed it? :-) I missed that completely, you can check the code - there should be no similarities whatsoever. I was entirely inspired by my recent discovery of the possibilities of outline-minor-mode and Org-Babel. What a bad luck ... ;( But anyway, probably the best we can do is to bring both version to a usable state and then let the users decide if they want to use it - and which one. At first glance, the projects seem so different that a merge appears impossible or just to much work - and not worth the pain. > I'll save myself a pointer to "outorg", for later perusing and study. I'll do the same thing with 'poporg' ;) -- cheers, Thorsten
Re: [O] OT, but not really: todays XKCD
Jambunathan K writes: > "Dominik, Carsten" writes: > >> Hurray for Nicolas and Bastien to be brave and switch to the >> new exporter framework which is a thing of beauty. > > It is an umbrella statement and doesn't mean much in and of itself. > > Let me clarify, Bastien has very miniscule (~ZERO) contribution to the > new framework or the exporters. Jambunathan, please do not make the mistake of underestimating the effort required to manage a project like org. It is an often thankless job (thanks Bastien!) and much of what is done is behind the scenes and probably very often akin to herding cats. Nicolas has not worked in isolation, which is not intended to diminish his contributions of course. The fact that much of the continual evolution of org is so painless and yet so effective is a real indicator of how well Bastien is managing the whole process. 'nuff said. On to other things now... like actually using org to get work done! -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-975-g1eccd2
Re: [O] org-bullets extension
Bastien writes: > org-bullets.el is in the contrib/ directory. By the way, I like using this one! It works as well with the newer Org than it did with the previous one, or at least so far that I know. I do not know if it is adequate to discuss contrib/ packages here, let me apologize if I should rather not. There is one small problem with org-bullets.el which existed then, and which still exists. Let me try to describe the problem. This is merely a display problem, the Org file is OK. With org-bullets active, and using capture, I insert a line starting with "- " and followed by a link as a last item under a header which was previously closed. The header gets opened, with all items visible, including the one just inserted. However, for that last item, this one that just got inserted, the bullet of the following header and header text is visually concatenated at the end of that item. Typing C-l (recenter-top-bottom) repairs the display: the bullet and its text visually jump on the next line, where they belong. François P.S. I very often do this kind of capture, the contents of the generated link come from a Google Chrome tab URL and title. It is just a bit annoying, after each capture, having to type C-l to correct the display.
Re: [O] [ANN] outorg.el -- reverse Org-Babel
Thorsten Jolitz writes: > With 'outorg', you can stay in you favorite language's major-mode while > programming, but with a real Org-mode 'look-and-feel', and rapidly > switch to a temporary buffer in Org-mode for some comment editing. > Exiting the temporary buffer then stores the edited comment text back to > the original source-code buffer (out-commented with the language's > 'comment-start' character). Hi, Thorsten. Just from reading your description, "outorg" seems strangely similar to "poporg" (https://github.com/pinard/poporg), which I announced on this list maybe two weeks ago. I would presume you missed it? :-) I'll save myself a pointer to "outorg", for later perusing and study. François
Re: [O] OT, but not really: todays XKCD
"Dominik, Carsten" writes: > is just too good to not share here, together with this > piece of data: > >$ grep defcustom lisp/*el contrib/lisp/*el |wc -l >1213 Scary! But indicative of the power of org I guess. > Hurray for Nicolas and Bastien to be brave and switch to the > new exporter framework which is a thing of beauty. Lets > help them to fix the bugs as quickly as possible and then > make those small adaptations in our workflow - it will be > worth it. +1 I think it's worth making clear that my concerns last week, with respect to moving to the new exporter, were with the move taking place without a clear idea of what workflow changes were required, whether small or not. The subsequent emails to this list, by Nicolas but also by many others, has made a significant difference. I have moved over to the new exporter exclusively, with actually little change to my workflow incredibly! Things are going well but I do seem to be encountering some very obscure bugs, mostly to do with columns in beamer export. I've not been able to come up with a suitable minimal example yet unfortunately: when I take a slide which has problems out of the whole presentation and put it into a single slide document, it works... :( Anyway, work in progress. In any case, thanks are due, of course, to Nicolas and Bastien but I would also like to express my thanks to all other contributors to org, be they contributors to actual code or because of their engagement on this list! All are required for org to continue being the indispensable part of my life and all are appreciated greatly. thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-975-g1eccd2
[O] Links to whole files recently changed
Hi, people. In the recent days, I noticed that org-store-link, when the cursor is on the #+TITLE line of an Org file, saves the information in such a way that a later org-insert-link creates the link by repeating the title before and after "::". I think that not so long ago, the "::" and what follows was not there. The effect is that when one tries to follow a link with the title repeated before and after "::", Org asks if it should create the header. I quickly read on the list, not so long ago, that someone else described a similar problem; I guess it might be the same problem. For example, I have a "Testing.org" file which begins with: #+TITLE: Testing The inserted link corresponding to this first file is: [[file:Testing.org::Testing][Testing]] while it should probably be: [[file:Testing.org][Testing]] The link comment likely comes from the text after #+TITLE, which is OK. François
Re: [O] edit-src on read-only files
>> it seems like org-mode should prevent that. >Yes, this is now the case in master. Thanks! great -- thank you!!
Re: [O] Invalid read syntax (#) in org-element parse tree
Nicolas Goaziou writes: Hello, > I'm not sure about what you want to do with the parse tree. The usual > function to work with it is `org-element-map'. You may want to have > a look at its docstring, as it contains examples. I want to write an 'unusual' backend that does not need anything else from the exporting framework but the parse-tree as a list. So all I need would be a workaround for this read-error issue, i.e. a tip how to get a version of the parse tree that can be used as list in a Lisp program. I could not find any explanation for the '#1' and '#2' syntax I encountered, so I don't really know what its all about. -- cheers, Thorsten
Re: [O] LaTeX export: Theorem with an author
Hi, > > #+begin_theorem :options [Him] > > slkdfj > > #+end_theorem > > This isn't future-proof. If, for example, we need to add options for the > HTML back-end, there will be a syntax conflict. The rule is the > following: > > - If the toggle are global, allow them on the block opening string > (i.e. src-block and code toggles) > > - For back-end specific value, use attributes. Fair enough. Although as Andreas said, something backend-agnostic to specify meta-data could still make sense at some point, which each backend could choose to implement as reasonable or ignore. You're right that setting LaTeX to add [Author] is probably not one of those cases. Cheers, /v > > > Regards, > > -- > Nicolas Goaziou
Re: [O] How to pass a block of text to a code block as data?
Michael Baum writes: > Sean, that helps too, thank you. Now that you and Sebastien have gone to > all this trouble I found the part of the manual that sort of describes > this, but I clearly didn't understand it before. Possible needs a more > worked-out example for the slow among us, like self. > Patches are welcome, especially documentation patches. [...] > > NOTICE THAT while both return the result as Example text, the first simple > prepends each line with a colon, simple Example form, and the second wraps > the result in an Example block without altering the lines. > > Not sure why? Is this just a function of the number of lines of the text? > Yes, this is a function of the number of lines in the output text. You can control where this switch is made by changing the value of org-babel-min-lines-for-block-output. Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] How to pass a block of text to a code block as data?
Sean, that helps too, thank you. Now that you and Sebastien have gone to all this trouble I found the part of the manual that sort of describes this, but I clearly didn't understand it before. Possible needs a more worked-out example for the slow among us, like self. I've noticed one curious thing in trying a perl example. See first: -8<-- #+name: wake #+BEGIN_EXAMPLE riverrun, past Eve and Adam's, from swerve of shore to bend of bay, brings us by a commodius vicus of recirculation back to Howth Castle and Environs. Sir Tristram, violer d'amores, fr'over the short sea, had passen- core rearrived from North Armorica on this side the scraggy isthmus of Europe Minor to wielderfight his penisolate war: nor had topsawyer's rocks by the stream Oconee exaggerated themselse to Laurens County's gorgios while they went doublin their mumper all the time: nor avoice from afire bellowsed mishe mishe to #+END_EXAMPLE #+begin_src perl :var inlines=wake :results output foreach $aln (split(/$/,$inlines)) { print $aln; } #+end_src #+results: : riverrun, past Eve and Adam's, from swerve of shore to bend : of bay, brings us by a commodius vicus of recirculation back to : Howth Castle and Environs. : Sir Tristram, violer d'amores, fr'over the short sea, had passen- : core rearrived from North Armorica on this side the scraggy : isthmus of Europe Minor to wielderfight his penisolate war: nor : had topsawyer's rocks by the stream Oconee exaggerated themselse : to Laurens County's gorgios while they went doublin their mumper : all the time: nor avoice from afire bellowsed mishe mishe to -8<-- and then a more complicated block that's closer to my real task: -8<-- #+NAME: job2 #+BEGIN_EXAMPLE !START !ID:7655 !DATE:02/10/2013 !CLOSE:03/15/2013 !UNTILFILLED: !POSITION:Science Editor !COMPANY:East Newark Times Herald News and World Defender !BEGIN-DESCRIPTION Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. !END-DESCRIPTION !BEGIN-SPECIAL Duis eget lorem ac odio lobortis suscipit nec et neque. Sed at quam ut mauris scelerisque congue id eget dui. Quisque tellus lectus, tristique eu posuere in, faucibus vitae urna. Duis vitae orci purus, quis euismod augue. !END-SPECIAL !SALARY:16.67 per hour !BEGIN-CONTACT Please submit online at http://enthnawd.org/jobs !END-CONTACT !END #+END_EXAMPLE #+begin_src perl :var inlines=job2 :results output foreach $aln (split(/$/,$inlines)) { print $aln; } #+end_src #+results: #+begin_example !START !ID:7655 !DATE:02/10/2013 !CLOSE:03/15/2013 !UNTILFILLED: !POSITION:Science Editor !COMPANY:East Newark Times Herald News and World Defender !BEGIN-DESCRIPTION Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. !END-DESCRIPTION !BEGIN-SPECIAL Duis eget lorem ac odio lobortis suscipit nec et neque. Sed at quam ut mauris scelerisque congue id eget dui. Quisque tellus lectus, tristique eu posuere in, faucibus vitae urna. Duis vitae orci purus, quis euismod augue. !END-SPECIAL !SALARY:16.67 per hour !BEGIN-CONTACT Please submit online at http://enthnawd.org/jobs !END-CONTACT !END #+end_example -8<-- NOTICE THAT while both return the result as Example text, the first simple prepends each line with a colon, simple Example form, and the second wraps the result in an Example block without altering the lines. Not sure why? Is this just a function of the number of lines of the text? Michael -- Michael Baum You should never have your best trousers on when you go out to fight for freedom and truth. - Ibsen
Re: [O] Invalid read syntax (#) in org-element parse tree
Hello, Thorsten Jolitz writes: > here is an excerpt of a parse tree produced with > 'org-element-parse-buffer': > > ,- > | (section (:begin 1 :end 624 :contents-begin > | 1 :contents-end 623 :post-blank 1 :parent #0) (keyword (:key > | TITLE :value Program "Blues for Icke" :begin 1 :end > | 39 :post-blank 0 :post-affiliated 1 :parent #1))) > `- > > When I evaluate a function with this list as data, I get an error: > > , > | Debugger entered--Lisp error: (invalid-read-syntax "#") > | read(#) > | preceding-sexp() > | eval-last-sexp-1(t) > | eval-last-sexp(t) > | eval-print-last-sexp() > | call-interactively(eval-print-last-sexp nil nil) > ` [...] > There are a lot of usages of '#' in Emacs Lisp, but I couldn't figure > out how (and why) it is used in ':parent #1'. See (info "(elisp) Read Syntax for Circular Objects") > Nic Ferrier wrote an exhaustive library with "routines for working with > key/value data structures like hash-tables and alists and plists" > (https://github.com/nicferrier/emacs-kv/blob/master/kv.el), but I cannot > apply any of the functions due to the read error. Do I really have to > treat the parse tree as text first and eliminate the '#' before I can > use it as list in Emacs Lisp, or did I simply manage to get the wrong > represantation of the parse tree somehow? I'm not sure about what you want to do with the parse tree. The usual function to work with it is `org-element-map'. You may want to have a look at its docstring, as it contains examples. Regards, -- Nicolas Goaziou
[O] Installation problem? (new exporter)
Hi, gang. I've difficulty to get the new exporter into movement. After trying for some time, I'm giving into this mailing list for help or advice. First, "C-c C-e" yields "Cannot open load file: org-export". I guess that some old autoload is hiding somewhere, but I just do not find it. Command "C-h k C-c C-e" tersely says: org-export-dispatch is an interactive autoloaded Lisp function. [Arg list not available until function definition is loaded.] Not documented. Debugging on error is terse as well: Debugger entered--Lisp error: (file-error "Cannot open load file" "org-export") On this Ubuntu 12.10, I moved /usr/share/emacs/23.4/lisp/org/ and /share/emacs23/site-lisp/org-mode/ elsewhere, just in case. I had no problems before using a recent Org, letting these older directories there, but this does not mean there were no problem, of course. To install Org, I merely "git clone" or "git pull" it, and then use "make". In the Make output, I see that autoloads are regenerated. Second, the following Makefile entry (reduced) does not work anymore for me: all: emacs -Q --batch --load publish.el --funcall org-publish-all Here is file "publish.el" (reduced): (defvar api-org-distribution "~/emacs/_/org-mode") (add-to-list 'load-path (concat api-org-distribution "/lisp")) (require 'org) (message (org-version)) (setq org-publish-project-alist `(("api" :base-directory "~/control3/api/" :publishing-directory "~/control3/api-html" ))) The "~/control3/api/" directory is already populated with many Org files by another program. Running "make" yields: 7.9.3e No publishing function chosen and no output is produced. Sigh! :-) François
Re: [O] Problem with org-html-format-latex
> > so simply testing > > on the value of processing-type would work better, maybe? > > Yes, should be okay now, let me know! Nope, exactly the same. cache-relpath and cache-dir are not allowed to be nil. Meaning that if processing-type is 'mathjax they should be set to _some_ string anyway (the contents will be ignored eventually, but far down the line unfortunately ...) Something like instead of your 'let' line works: (let ((cache-relpath "") (cache-dir "") bfn) /v
Re: [O] New exporter macro question
Hello, Carsten Dominik writes: > I am porting my websites to the new exporter, finally. Much is very smooth. > I do have a problem with macros: > > > * Macro definition > > >#+MACRO: thumbright #+ATTR_HTML: style="float:right;width:$1;margin:0px > 20px 0px 20px;" \n [[./Content/$2/thumb.jpg]] > > > > * Macro call > >{{{thumbright(300px,Wiskunde)}}} > > > > > * This used to expand to > > style="float:right;width:300px;margin:0px 20px 0px 20px;" > alt="./Content/Wiskunde/thumb.jpg" /> > > > * But now it expands to nothing > I am sure I am missing something basic. Thanks! Macros have been downgraded a bit, as there was some overlapping with Babel functionalities. In particular, they are meant to replace objects, not elements, which means they cannot contain newline characters anymore. You can use a Babel block to generate the Org code you want. You can also try the following macro, which will generate the HTML code you want: #+MACRO: thumbright @@html:@@ Regards, -- Nicolas Goaziou
Re: [O] new exporter fails to output footnotes?
Samuel Wales writes: > Surely this is pilot error someplace. > > (org-export-to-buffer > 'html > (get-buffer-create "test") > t > nil > t) > > *** test > asasdf[fn::test] > > *** output > > asasdf href="#fn.1">1 It should be fixed in master. Could you confirm it? Thank you for reporting the bug. Regards, -- Nicolas Goaziou
Re: [O] ocaml babel no longer works?
Hello, Eric Schulte writes: > Thanks for looking into this. I've applied a patch to ob-ocaml.el which > should handle the two different tuareg execution functions. Thanks a lot. About the thing "getting stuck", I made some progress. My error was that I did not add ";;" at the end of my ocaml phrase, which resulted in an error in the toplevel: #+begin_quote Objective Caml version 3.12.1 # let x = 2 in x "org-babel-ocaml-eoe";; Characters 13-14: let x = 2 in x ^ Error: This expression is not a function; it cannot be applied #+end_quote As you see, it's trying to apply the 'x' to the "oeo" thing. My guess is that babel waits until seeing this special string before sending the result back. By the way, this allows for some fun things, like this: #+BEGIN_SRC ocaml let f x = () in f #+END_SRC make babel stuck because the interpreter is in this state: #+begin_quote # let f x = () in f "org-babel-ocaml-eoe";; - : unit = () #+end_quote So I have a suggestion and two feature requests. The suggestion: instead of appending '"org-babel-ocaml-eoe";;' to the code, how simply put ';;' (which will make sure everything is flushed) then detect the toplevel is done by seeing the string '# ' at the beginning of the line? Would there be an issue with the fact that this line does not have a newline? If so, an alternative suggestion would be to use the longer ';; "org-babel-ocaml-eoe";;' which makes sure the phrase in the input won't interact with the marker. The first feature requests: if there is an error, could it be parsed? (It probably always start with 'Error: '). Then the error could be put in the result block, instead of waiting for the marker that will never appear. The second feature request: I want to use this for my ocaml lab classes (I'm thinking of giving them an org file they have to complete by writing the caml code). Could it be possible to have an option for the full output of the compiler (and not just the result) to be printed? I see it does it when it does not recognize the type of the output. So I guess such an option would be applied to either org-babel-ocaml-parse-output or the place where it's called. Thanks a lot for any suggestion as how to implement this. I think I see how to do the second one (except I don't know how to add a configuration variable to toggle it). I have no idea about the first one, though. Alan
Re: [O] OT, but not really: todays XKCD
Yagnesh Raghava Yakkala writes: > But I am disappointed to see that you discourage/attack current Org's > maintainer directly. I think this won't help anyone in anyway. If I say Yagnesh has made zero contributions to Tamil Poetry does it amount to attacking you. Think about it. --
Re: [O] compilation issues of new export framework
Nicolas Goaziou writes: > I found that inlining it was an overkill. So the change is intentional. Thanks for the confirmation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] compilation issues of new export framework
Achim Gratz writes: > Nicolas Goaziou gmail.com> writes: >> On the other hand, `org-element-type' and al. from org.el are called >> less often. So, it is not a problem if they are compiled as function >> calls. > > They are normally not compiled as function calls, only in single mode. > > Regarding commit 6b7101b91, did you intend to demote org-element-nested-p to a > defun or was this just a leftover from the earlier experiment? I found that inlining it was an overkill. So the change is intentional. Regards, -- Nicolas Goaziou
Re: [O] org-element-paragraph-parser fails
Hello, Charles Berry writes: > Remove the spaces before #+name OR take out the '- item' and > org-export-dispatch > succeeds. > > As is, it fails with > > org-element-paragraph-parser: Invalid search bound (wrong side of point) > > > , > | * export dispatcher > | > | - item > | > | #+name: xyz > | #+BEGIN_SRC emacs-lisp > | (pwd) > | #+END_SRC > ` This should be fixed. Thank you for reporting this. Note that it won't give you the result you're probably expecting. The NAME keyword belongs to the list whereas the src-block doesn't. The are unrelated. So the affiliated keyword will be parsed as a regular keyword and the block will have no name. Regards, -- Nicolas Goaziou
Re: [O] OT, but not really: todays XKCD
Jambunathan K writes: > "Dominik, Carsten" writes: > >> Hurray for Nicolas and Bastien to be brave and switch to the >> new exporter framework which is a thing of beauty. > > It is an umbrella statement and doesn't mean much in and of itself. Echoing Carsten's message, I tip my hat to Bastien for moving the Org mode community along this path, and to Nicolas for a remarkable piece of software engineering. I'm looking forward to what the future brings, and to a long and productive relationship with the Org mode community. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Fwd: Re: Bug? in texinfo exporter
Aloha Nicolas and Jon, Nicolas Goaziou writes: > t...@tsdye.com (Thomas S. Dye) writes: > >> Aloha Jon, > > [...] > >> Yes, I believe you are right. The commas are not the culprits. >> Apologies for the red herring. >> >> Perhaps Nicolas should revert the commit? Could you check if this is >> the right thing to do? > > My fix isn't about the comma. Didn't it work? The particular link I used in the example now works. Thanks. I wasn't sure what was done and worried that my red herring had made it into the code. Glad to know that it didn't. > >> I *have* found a bug/limitation of the texinfo exporter. If a link is >> split between two lines the exporter doesn't handle it correctly. A >> split link is exported like @ref{A-split-link}, when it should be @ref{A >> split link}, I think. > There's no such limitation. Could you provide an ECM for that? Yes, here is an ECM. - Begin ECM -- * A long headline that typically breaks across lines with M-q Blah. * Concise headline The problem comes with links that are split across lines, e.g. [[A long headline that typically breaks across lines with M-q]]. They work in the Org mode buffer, but not when exported to texinfo. * Editing setup #+name: setup-editing #+header: :results silent #+header: :eval no-export #+begin_src emacs-lisp (require 'ox-texinfo) (define-key org-mode-map (kbd "C-c e") 'org-export-dispatch) (setq org-pretty-entities nil) (setq org-src-preserve-indentation t) (setq org-confirm-babel-evaluate nil) (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . t) (sh . t))) (add-to-list 'org-export-snippet-translation-alist '("info" . "e-texinfo")) #+end_src -- End ECM --- Here is the makeinfo output: poto:orgmanual dk$ makeinfo --force org-texi-link.texi /Users/dk/org/orgmanual//org-texi-link.texi:55: Cross reference to nonexistent node `A-long-headline-that-typically-breaks-across-lines-with-M-q' (perhaps incorrect sectioning?). Note the hyphens between the words of the headline/link. All the best, Tom -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
[O] Invalid read syntax (#) in org-element parse tree
Hi List, here is an excerpt of a parse tree produced with 'org-element-parse-buffer': ,- | (section (:begin 1 :end 624 :contents-begin | 1 :contents-end 623 :post-blank 1 :parent #0) (keyword (:key | TITLE :value Program "Blues for Icke" :begin 1 :end | 39 :post-blank 0 :post-affiliated 1 :parent #1))) `- When I evaluate a function with this list as data, I get an error: , | Debugger entered--Lisp error: (invalid-read-syntax "#") | read(#) | preceding-sexp() | eval-last-sexp-1(t) | eval-last-sexp(t) | eval-print-last-sexp() | call-interactively(eval-print-last-sexp nil nil) ` from the doc in 'org-element.el' I learn that: , | ;; Notwithstanding affiliated keywords, each greater element, element | ;; and object has a fixed set of properties attached to it. [...] | | ;; `:parent' which refers to the element or object containing it. [...] | | ;; Lisp-wise, an element or an object can be represented as a list. | ;; It follows the pattern (TYPE PROPERTIES CONTENTS), where: | ;; TYPE is a symbol describing the Org element or object. | ;; PROPERTIES is the property list attached to it. See docstring of | ;; appropriate parsing function to get an exhaustive | ;; list. | ;; CONTENTS is a list of elements, objects or raw strings contained | ;;in the current element or object, when applicable. | ;; | ;; An Org buffer is a nested list of such elements and objects, whose | ;; type is `org-data' and properties is nil. ` There are a lot of usages of '#' in Emacs Lisp, but I couldn't figure out how (and why) it is used in ':parent #1'. Nic Ferrier wrote an exhaustive library with "routines for working with key/value data structures like hash-tables and alists and plists" (https://github.com/nicferrier/emacs-kv/blob/master/kv.el), but I cannot apply any of the functions due to the read error. Do I really have to treat the parse tree as text first and eliminate the '#' before I can use it as list in Emacs Lisp, or did I simply manage to get the wrong represantation of the parse tree somehow? Thanks for any advice. -- cheers, Thorsten
Re: [O] [PATCH] Protect org-agenda-prepare-buffers with org-unmodified
Hi Francesco, "Francesco Pizzolante" writes: > This patch protects changes done in org-agenda-prepare-buffers with > org-unmodified instead of saving/restoring buffer-modified-p. This avoids > modification hooks to run. Applied, thanks! -- Bastien
Re: [O] navigating between non-code blocks?
Hi Sébastien and François, "Sebastien Vauban" writes: > Indeed... Fixed. > And, don't know why, but the speed key `F' is not working for me, on a freshly > pulled Org: Also fixed, thanks. -- Bastien
Re: [O] "make test" failure
Hi Nick, Nick Dokos writes: > Just pulled and ran "make test". I get one failure with the > appended backtrace: I submitted this patch to Nicolas so that he can approve/apply it. I think the test is wrong, not the code. diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index dac5fd2..561ac98 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -677,10 +677,7 @@ Outside." ;; headline at the same level. (goto-line 3) (org-backward-element) -(should (looking-at (regexp-quote "* Head 1"))) -;; 4.3. At the first top-level headline: should error. -(goto-line 2) -(should-error (org-backward-element))) +(should (looking-at (regexp-quote "** Head 1.1" ;; 5. At beginning of first element inside a greater element: ;;expected to move to greater element's beginning. (org-test-with-temp-text "Before.\n#+BEGIN_CENTER\nInside.\n#+END_CENTER" -- Bastien
Re: [O] org-bullets extension
E Sabof writes: > What is the current status of the package? Was it accepted? Was it > superseded? org-bullets.el is in the contrib/ directory. > If it wasn't superseded, I might spend some time re-implementing it. I think it would be nice to adapt Jambunathan's solution for Org's core: something like a `org-replace-leading-stars' that, when non-nil, would be used as the char/string for compose-region. Then users could turn this on/off using #+STARTUP. What do you think? -- Bastien
Re: [O] Bug: org-insert-heading-respect-content inserts at the wrong level if target heading is invisible [7.9.2 (release_7.9.2-883-g6fb36e.dirty @ /home/dlm/share/org-mode.git/lisp/)]
Hi James, James Harkins writes: > I'm resending the issue that I reported the other day, now with a > MCE. Sorry for the delay on this -- and thanks for the detailed reports. I tried not to get lost in the details actually... so I ended up using the attached fix. It works here, i.e. C-u C-RET inserts a new heading at the right place, but I'm not using org-mobile.el so I'm not 100% sure if it works for you. Can you test and confirm? Thanks! >From 808779ada5a35b69aca12e35723b22725aebf0f3 Mon Sep 17 00:00:00 2001 From: Bastien Guerry Date: Mon, 11 Feb 2013 18:27:21 +0100 Subject: [PATCH] Fix `org-insert-heading-respect-content' * org-mobile.el (org-mobile-edit): DTRT when insert a heading in an invisible region. * org.el (org-insert-heading-respect-content): New `invisible-ok' parameter. Add docstring. (org-insert-todo-heading-respect-content): Add docstring. Thanks to James Harkins for the extra detailed reports and the proposed solutions, both for org.el and org-mobile.el. --- lisp/org-mobile.el | 2 +- lisp/org.el| 8 +--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/lisp/org-mobile.el b/lisp/org-mobile.el index a410de0..293d2a0 100644 --- a/lisp/org-mobile.el +++ b/lisp/org-mobile.el @@ -1064,7 +1064,7 @@ be returned that indicates what went wrong." (if (org-on-heading-p) ; if false we are in top-level of file (progn (end-of-line 1) - (org-insert-heading-respect-content) + (org-insert-heading-respect-content t) (org-demote)) (beginning-of-line) (insert "* ")) diff --git a/lisp/org.el b/lisp/org.el index 623c374..10168a5 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7231,12 +7231,14 @@ This is a list with the following elements: (org-move-subtree-down) (end-of-line 1)) -(defun org-insert-heading-respect-content () - (interactive) +(defun org-insert-heading-respect-content (invisible-ok) + "Insert heading with `org-insert-heading-respect-content' set to t." + (interactive "P") (let ((org-insert-heading-respect-content t)) -(org-insert-heading t))) +(org-insert-heading t invisible-ok))) (defun org-insert-todo-heading-respect-content (&optional force-state) + "Insert TODO heading with `org-insert-heading-respect-content' set to t." (interactive "P") (let ((org-insert-heading-respect-content t)) (org-insert-todo-heading force-state t))) -- 1.8.1.2 -- Bastien
[O] "make test" failure
Just pulled and ran "make test". I get one failure with the appended backtrace: Nick Test test-org/backward-element backtrace: (if (unwind-protect (setq value-4576 (apply fn-4574 args-4575)) (set (let (form-description-4578) (if (unwind-protect (setq value-4576 (a (let ((value-4576 (quote ert-form-evaluation-aborted-4577))) (let (f (let ((fn-4574 (function looking-at)) (args-4575 (list (regexp-quote (progn (org-mode) (progn (insert "\n* Head 1\n** Head 1.1\n*** Head (unwind-protect (progn (org-mode) (progn (insert "\n* Head 1\n** Hea (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (let ((temp-buffer (generate-new-buffer " *temp*"))) (save-current-b (lambda nil (let ((temp-buffer (generate-new-buffer " *temp*"))) (sa #[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\317\320%DC funcall(#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\31 ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc #[0 "r\304\305!q\210\306 d\307\223)\310\311\312\313\314\315!\316\" funcall(#[0 "r\304\305!q\210\306 d\307\223)\310\311\312\313\314\315 ert-run-test([cl-struct-ert-test test-org/backward-element "Test `or ert-run-or-rerun-test([cl-struct-ert--stats "\\(org\\|ob\\)" [[cl-st ert-run-tests("\\(org\\|ob\\)" #[385 "\306\307\"\203D
Re: [O] Bug in org-insert-heading-after-current?
Hi Thorsten, Thorsten Jolitz writes: > having added a property drawer with two entries: > > ,- > | * Definitions > | :PROPERTIES: > | :exports: both > | :results: replace > | :END: > `- > > I evaluate: > > ,--- > | (outline-previous-heading) > | (org-insert-heading-after-current) > `--- > > and get: > > , > | * Definitions > | :PROPERTIES: > | :exports: both > | :results: replace > | * > | [2013-01-28 Mo 17:48] > | :END: > ` > > while the new heading should be below the :END: I cannot reproduce this with the current HEAD of the git repository and a bare emacs -Q. Is there other info I need to reproduce this? Thanks! -- Bastien
Re: [O] New exporter macro question
Nick Dokos wrote: > Carsten Dominik wrote: > > > OK, I see, this seems to be because the "\n" is no longer > > interpreted as a newline character upon macro expansion, so the > > entire text ends up in the ATTR_HTML line and is treated as a > > comment. > > It seems to be coming from deep with emacs: if I create a buffer > with > > x y z \ x y z > > and evaluate (with point somewhere on that line) > > (buffer-substring-no-properties (point-at-bol) (point-at-eol)) > > I get "x y z \\ x y z", so the backslash is escaped willy-nilly. > > This happens in org-element-keyword-parser. I don't know if the > macro expansion would replace \n with a newline absent the extra > backslash, but I'm sure that its presence does not help any. > Even if I delete the extra backslash from the value of the macro in org-macro-initialize-templates, the regexp fails to properly match: , | ;; Install buffer-local macros. | (org-with-wide-buffer | (goto-char (point-min)) | (while (re-search-forward "^[ \t]*#\\+MACRO:" nil t) |(let ((element (org-element-at-point))) |(when (eq (org-element-type element) 'keyword) | (let ((value (org-element-property :value element))) |(when (string-match "^\\(.*?\\)\\(?:\\s-+\\(.*\\)\\)?\\s-*$" value) | (funcall set-template | (cons (match-string 1 value) | (or (match-string 2 value) "") ` OTOH, if I modify the cell argument inside set-template[fn:1] to get rid of the extra backslash, the macro expansion happened as expected. Nick Footnotes: [fn:1] This is obviously a gross hack, only meant as a debugging aid. In fact, I didn't even code it up: I just stepped through the thing with edebug and slammed the modified value into the cell argument.
[O] A short introduction to YASnippet (was: [Bug] Yasnippet/Org: properties messed up when expanding $1)
* Bastien wrote: > Hi Karl, Hi! > I've installed Yasnippet (from GNU ELPA) but I think I need more > help on how to test it... expanding with TAB in text-mode and in > yas-minor-mode doesn't produce anything useful. Does it produce something at all? > Can you make a recipe for yas-n00bs? Sure. If yasnippet is installed and loaded, you should get an additional menu entry called «YASnippet». You find out, where your snippet folder is located. Mine is «~/.emacs.d/snippets». yasnippet is pretty straight forward: every text file within the snippet folder is a defined snippet. If not stated otherwise in the header of the file, the name of the snippet file is the command which is used to expand. You can define snippets that are only available in certain modes: snippets within «$SNIPPETDIR/text-mode/org-mode» are only available in Org-mode. Following snippet is only available in Org-mode and is expanded by entering «test» followed by TAB: ,[ Snippet «~/.emacs.d/snippets/text-mode/org-mode/test» ] | # name : Testing yasnippet/org issue | # -- | | ** Test ${1:test} | :PROPERTIES: | :ID: $1 | :END: ` AFAIR the header is optional. Within the header, you can define additional description, alternative name, author, and so forth. If you add new snippets, you can choose «YASnippet/Reload everything» from the Emacs menu. I guess this is «yas/reload-all». Within a snippet, the first «$1» results in putting the cursor at this point and «asking» the user to enter a string. You can define a default string with «${1:test}» where «test» is the default string for «$1». All other occurrences of «$1» will be replaced by the very same user string which is quite handy: you have to enter it only once and it gets replaced multiple times. The snippet above with «$1» as «foo bar» should result in: ,[ expanded snippet «test» with «foo bar» ] | ** Test foo bar | :PROPERTIES: | :ID: foo bar | :END: ` For further documentation, please refer to [1]. At my side, any «$x» within the PROPERTIES drawer messes up the line. YASnippets are very easy to set up, very handy to use. IMHO, everybody should use something like yasnippet in his/her daily workflow. 1. http://capitaomorte.github.com/yasnippet/#how-to-use-yasnippet -- Karl Voit
Re: [O] latex code block evaluation
henry atting writes: > I have this latex code block: > > #+begin_src latex :file foo.pdf > \documentclass{article} > \begin{document} > ...some text... > \end{document} > #+end_src > > After evaluation the resulting file looks like this: > > > article ...some text... > > I do not understand this. As far as I know it is possible to define the > latex documentclass within a code block. Currently the machinery used to generate images of inline latex equations is used to evaluate latex code blocks. So e.g., the following works as "expected". #+begin_src latex :file write-fisher.pdf :results raw \begin{equation*} P_{i} = \frac{(2N)!}{i! (2N-i)!} p^{i}q^{2N-i} \end{equation*} #+end_src #+RESULTS: [[file:write-fisher.pdf]] In this case it is all a matter of balancing what the majority of users think is "expected". If specifying a particular document class is important, than I am sure that it shouldn't be hard to update the org-babel-execute:latex function to check for the presence of \begin{document} and handle those cases differently (in a similar way to how org-babel-execute:C checks for a main function). If specifying the document class is not required your example could be converted to the (arguably preferable) example below. #+begin_src latex :file foo.pdf :results raw ...some text... #+end_src #+RESULTS: [[file:foo.pdf]] Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] block quotes in prose?
Hi Bastien and Peter, Bastien wrote: > Peter Salazar writes: > >> Now the question is: How do I make org-mode recognize the ">" prefix as a >> demarcator of a code block, so that my document remains readable as >> Markdown? > > You can't -- using ":" as the prefix for fixed-width regions is hardcoded. > If we allow to customize this, it will lower the "exchangeability" of .org > files between users (this exchangeability is already quite low due to the > many options user have.) That 'd have been excellent: copies of (replies to) emails wouldn't have needed to be protected anyhow. But, yes, I can understand it's too late... Best regards, Seb -- Sebastien Vauban
Re: [O] block quotes in prose?
Hi Peter, Peter Salazar writes: > Now the question is: How do I make org-mode recognize the ">" prefix > as a demarcator of a code block, so that my document remains readable > as Markdown? You can't -- using ":" as the prefix for fixed-width regions is hardcoded. If we allow to customize this, it will lower the "exchangeability" of .org files between users (this exchangeability is already quite low due to the many options user have.) Best, -- Bastien
Re: [O] latex code block evaluation -- Eric?
Hi Henry, henry atting wrote: > "Sebastien Vauban" writes: >> henry atting wrote: >>> I have this latex code block: >>> >>> #+begin_src latex :file foo.pdf >>> \documentclass{article} >>> \begin{document} >>> ...some text... >>> \end{document} >>> #+end_src >>> >>> After evaluation the resulting file looks like this: >>> >>> article ...some text... >>> >>> I do not understand this. As far as I know it is possible to define the >>> latex documentclass within a code block. >> >> Could you be more explicit? Do you want to use that to pass parameters to >> the >> LaTeX backend? If yes, why not using the "#+LaTeX:" directive (not sure >> they're still supported with the exact same syntax as before -- I've not yet >> merged my documents). And that brings us to the most important question: old >> or new exporter? >> >> Eventually, can you send a real ECM, or your real use case? > > Ah, I see, I was unclear. > In this case I simply want to evalutate this code block with `C-c C-c'. > I do not use the orgmode LaTeX exporter, only the HTML exporter. > Finally I will create org files with LaTeX code blocks which I will export to > HTML. And that's all. HTML export works fine with the old or the new > exporter. > > Though in this case it is not really indispensable I only was wondering why > code block evalution does not work as expected. Why is > `\documentclass{article}' not recognized properly? To be sure to understand, what are you expecting when you're evaluating the LaTeX code block? Its content to be automagically converted to a PDF file thru the LaTeX chain? AFAIK, this does not work. I'd like it to be the case, but Eric Schulte once explained it was (too?) difficult. Dunno if it's still on his task list. The workaround was to tangle to a TeX file, and from there to compile to a PDF via AUCTeX. Yes, not sexy, I know. Best regards, Seb -- Sebastien Vauban
Re: [O] [Bug] Yasnippet/Org: properties messed up when expanding $1
Hi Karl, Karl Voit writes: >> I do face strange behavior when using yasnippet with Org-mode: > > So there does not seem to be anybody who is able to fix this issue. > Is there at least somebody who can confirm this weird bug? I've installed Yasnippet (from GNU ELPA) but I think I need more help on how to test it... expanding with TAB in text-mode and in yas-minor-mode doesn't produce anything useful. Can you make a recipe for yas-n00bs? Thanks! -- Bastien
Re: [O] OT, but not really: todays XKCD
[RESENT to the list only now] Dear Jambunathan, I respect your contributions to Org/Emacs/FreeSoftware a lot. But I am disappointed to see that you discourage/attack current Org's maintainer directly. I think this won't help anyone in anyway. Thanks., -- ఎందరో మహానుభావులు అందరికి వందనములు. YYR
Re: [O] orgstruct-mode with custom headline prefix
Christopher Schmidt writes: > Christopher Schmidt writes: >> Here is the patch. Now one just needs >> >> ;; Local Variables: >> ;; eval: (orgstruct-mode 1) >> ;; orgstruct-heading-prefix-regexp: ";;; " >> ;; End: > > This is in master now. The commit is a3f6570. Thanks a lot! -- Bastien
Re: [O] edit-src on read-only files
Hi Greg, Greg Minshall writes: > hi. i use RCS on my .org files. it's happened to me more than once (>1 > ==> "shame on me") that i've entered "C-c '" on a read-only .org file, > spent some time editing the source code fragment, then done "C-c '", > only to lose my edits, as the original buffer was read-only. > > it seems like org-mode should prevent that. Yes, this is now the case in master. Thanks! -- Bastien
Re: [O] suggestion: M-m should move point to first word on line
Hi Meng Weng, Meng Weng Wong writes: > Ordinarily, M-m is bound to (back-to-indentation) – move point to > the first non-whitespace character on the line. It differs from C-a. > > Might it make sense for org-mode to override M-m? Not to override `M-m' but perhaps to define "*" as a syntactic whitespace character. Patch attached -- use with caution. I tested it a bit and it seems to work, but not all tests pass and there may be side-effects that I could not observe. In the meantime, I guess org-special-ctrl-a org-special-ctrl-a/e are useful enough, as already pointed. diff --git a/lisp/org.el b/lisp/org.el index 4555ed1..d6ae281 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5177,6 +5177,7 @@ The following commands are available: (org-set-tag-faces 'org-tag-faces org-tag-faces)) ;; Calc embedded (org-set-local 'calc-embedded-open-mode "# ") + (modify-syntax-entry ?* " ") (modify-syntax-entry ?@ "w") (modify-syntax-entry ?\" "\"") (if org-startup-truncated (setq truncate-lines t)) -- Bastien
Re: [O] Problem with org-html-format-latex
Vincent Beffara writes: > so simply testing > on the value of processing-type would work better, maybe? Yes, should be okay now, let me know! -- Bastien
Re: [O] [PATCH] Fix a number of potential infinite loops due to unsgined underflow.
Hi Tom, Tom Prince writes: > I discovered this, when trying to merge a file, with a tag that > overhangs the right margin. Trying to merge the following line > with itself (with --rmargin less than 10) the causes the driver > to output spaces forever: Good to know people are using Andrew's work! Andrew, are you still maintainer this git merge driver? Thanks, -- Bastien
Re: [O] org-fill-paragraph breaks timestamps
Hi William, William writes: > In plain lists, I sometimes insert timestamps in running text (for an item to > appear in the agenda), then fill it with org-fill-paragraph. Sometimes, the > timestamp is splitted (at any of both spaces), breaking the desired agenda > behavior. Fixed. > Is there something I can do for this not to happen ? Update (either the maint or the master branch) :-) Thanks! -- Bastien
[O] bug#13668: 24.2.93; strike-through in org mode
"Roland Winkler" writes: > On Sun Feb 10 2013 Bastien wrote: >> Please provide a patch. > > I'd much appreciate if the org developers could do that. I have > enough such things on my own emacs agenda, Done in Org's git repository, thanks. -- Bastien
Re: [O] freeplane exporter too?
writes: > would the new freemind exporter be able to handle files > created with freeplane, or would there have to be a > freeplane exporter too? Freeplane files and Freemind files > are similar, but not the same. > > Just something to consider... Here is a wiki page describing the freeplan format, if anyone needs to implement this new export backend: http://freeplane.sourceforge.net/wiki/index.php/Current_Freeplane_File_Format -- Bastien
Re: [O] Scheduling makes link disappear
Hi Thomas, Thomas Morgan writes: > Thanks! That fixes it and doesn't break any of the agenda views > that I use. Thanks for confirming, I've applied the patch now. All best, -- Bastien
Re: [O] Bug in org-src.el?
Hi Thorsten, Thorsten Jolitz writes: > when I export a (bit complicated) PicoLisp source block with ':results > html', I get an error: > > , > | error: "Invalid search bound (wrong side of point)" > ` Yes, I've seen this error too sometimes and it was not easy to fix when I tried to. Can you share the minimal code block to reproduce? Thanks, -- Bastien
Re: [O] Calling 'org-babel-mark-block' with 'M-x cmd' and 'M-: (cmd)'
Hi Thorsten, Thorsten Jolitz writes: > Interesting, I have to check what happens when I use this function in a > program. Kind of strange, though, is that a bug in > 'org-babel-mark-block' - or in Emacs itself? I think it may have been a temporary bug in Emacs. Can you reproduce it with a recent Emacs? Also, M-h is bound to `org-mark-element', which will mark a block (the whole block, not just its content). You might find it useful too! Best, -- Bastien
Re: [O] Make [C-c C-o] open link to auto create non-existing directory
Hi Chris, chris writes: > I found Emacs + Org-mode can not automatically create non-existing directory. > > For example: > > When I create a link [[file:Linux/Linux.org]], but this path does not exist. > When I open this link with [C-c C-o]. Emacs shows into: > Use [M-x make-directory RET RET] to create the directory and its parents > Setting current directory: no such file or directory, > /home/chrsi/Org/Wiki/Linux/ > > Is it possible make Org auto create non-existing directory ? Org behaves like Emacs here: in Emacs, if you find a file in a directory that does not exist, you get the same warning. A solution to automatically create the directory (with maybe just a confirmation step) would be needed for Emacs, not just for Org. Or is your need very specific to Org? -- Bastien
Re: [O] Feature: Group and limit items in agenda
Hi Muchenxuan, Muchenxuan Tong writes: > My intention is to limit the number of tasks in each category. Did you check (info "(org)Block Agenda") ? That's the way I would suggest: define a block agenda listing the various categories, then use `org-agenda-max-todos' in each of them to limit the number of TODOs. > For the new proposed 'org-agenda-max-todos', I can only limit the > number of TODOs in the whole TODO lists. > > Maybe for what I want, it's desirable to add a auto-split or > auto-group features, where a list of TODOs, can be split further into > multiple lists of TODOs, by a certain criteria (tags, category). > > What do you think about it? I understand defining block agendas is not as straightforward than the solution you envision, but my feeling is that allowing grouping+limits will have too much overlap with the block agenda functionality. Let me know if you find the path to happiness with a combinaison of block agendas and the new variables. Thanks, -- Bastien
Re: [O] New exporter macro question
Carsten Dominik wrote: > > On 11 feb. 2013, at 13:48, Carsten Dominik wrote: > > > > > Hi, > > > > I am porting my websites to the new exporter, finally. Much is very > > smooth. I do have a problem with macros: > > > > > > * Macro definition > > > > > > #+MACRO: thumbright #+ATTR_HTML: style="float:right;width:$1;margin:0px > > 20px 0px 20px;" \n [[./Content/$2/thumb.jpg]] > > > > > > > > * Macro call > > > > {{{thumbright(300px,Wiskunde)}}} > > > > > > > > > > * This used to expand to > > > >> style="float:right;width:300px;margin:0px 20px 0px 20px;" > > alt="./Content/Wiskunde/thumb.jpg" /> > > > > > > * But now it expands to nothing > > I am sure I am missing something basic. Thanks! > > OK, I see, this seems to be because the "\n" is no longer interpreted as a > newline character upon macro expansion, so the entire text ends up in the > ATTR_HTML line and is treated as a comment. > > Is there a way to get what I meant? > It seems to be coming from deep with emacs: if I create a buffer with x y z \ x y z and evaluate (with point somewhere on that line) (buffer-substring-no-properties (point-at-bol) (point-at-eol)) I get "x y z \\ x y z", so the backslash is escaped willy-nilly. This happens in org-element-keyword-parser. I don't know if the macro expansion would replace \n with a newline absent the extra backslash, but I'm sure that its presence does not help any. Nick
Re: [O] OT, but not really: todays XKCD
Hi Jambunathan, thanks for pointing out again that the new exporter is 99% Nicolas achievement. It's so obvious to me that I may be fooled in thinking that it's obvious to everyone. As for the donations, I also wish Nicolas can receive donations. If Nicolas makes this move, I'd be happy to have more donate buttons on the website to allow targeted donations. For the ones I received, I don't think I'm actually pretending to do more than what I do. Your choice of not asking for donation is yours, I respect that. I'm not a very talented programmer, I just happen to know enough of Emacs Lisp to help with a project like Org. I do this mainly for the thrill of learning new things and the pleasure of meeting nice and smart people online. There is one thing that I hope I'm good at: being polite and patient with people. Trying to help, even when I'm not the best one around here to give an answer. I don't know if you are a maintainer for a project of a comparable size than Org, but if you do, you know that being nice and willing to help is a big part of the job. It's important for two reasons: to keep a nice atmosphere on the list, so that people feel comfortable asking stupid questions; and to let other developers focus on their work (while you try to help newbies with their problems). It would have been difficult for you to focus on the ODT exporter or to Nicolas to focus on the new export engine if I didn't put enough energy to maintain the whole beast. At least I believe so. But I get the core of your message and I fully agree: kudos go to Nicolas for his work! I just hope I helped him somehow. Best, PS: I think I said it already but I'm not a benevolent dictator for life -- the ones I think would be good maintainers declined the offer so far. Just be patient :) -- Bastien
Re: [O] New exporter macro question
On 11 feb. 2013, at 13:48, Carsten Dominik wrote: > > Hi, > > I am porting my websites to the new exporter, finally. Much is very smooth. > I do have a problem with macros: > > > * Macro definition > > > #+MACRO: thumbright #+ATTR_HTML: style="float:right;width:$1;margin:0px > 20px 0px 20px;" \n [[./Content/$2/thumb.jpg]] > > > > * Macro call > > {{{thumbright(300px,Wiskunde)}}} > > > > > * This used to expand to > >style="float:right;width:300px;margin:0px 20px 0px 20px;" > alt="./Content/Wiskunde/thumb.jpg" /> > > > * But now it expands to nothing > I am sure I am missing something basic. Thanks! OK, I see, this seems to be because the "\n" is no longer interpreted as a newline character upon macro expansion, so the entire text ends up in the ATTR_HTML line and is treated as a comment. Is there a way to get what I meant? Thanks - Carsten
[O] Exporter question
Hi, In a file with some time stamps in headlines, is it still possible to get rid of them only for the Table of Contents, but to leave them in the headlines themselves? Thanks - Carsten
[O] New exporter macro question
Hi, I am porting my websites to the new exporter, finally. Much is very smooth. I do have a problem with macros: * Macro definition #+MACRO: thumbright #+ATTR_HTML: style="float:right;width:$1;margin:0px 20px 0px 20px;" \n [[./Content/$2/thumb.jpg]] * Macro call {{{thumbright(300px,Wiskunde)}}} * This used to expand to * But now it expands to nothing I am sure I am missing something basic. Thanks! - Carsten
Re: [O] Fwd: Re: Bug? in texinfo exporter
On Feb 11, 2013 1:59 AM, "Nicolas Goaziou" wrote: > > t...@tsdye.com (Thomas S. Dye) writes: > > > Aloha Jon, > > [...] > > > Yes, I believe you are right. The commas are not the culprits. > > Apologies for the red herring. > > > > Perhaps Nicolas should revert the commit? Could you check if this is > > the right thing to do? > > My fix isn't about the comma. Didn't it work? > Your fix seems to have worked from what I can see (it was what I was thinking of fixing at least). The comma was Tom's initial guess. > > I *have* found a bug/limitation of the texinfo exporter. If a link is > > split between two lines the exporter doesn't handle it correctly. A > > split link is exported like @ref{A-split-link}, when it should be @ref{A > > split link}, I think. > > > > If this is a limitation, please let me know so I can put all the links > > on one line. > > There's no such limitation. Could you provide an ECM for that? > I think Tom might be referring to when a line is hard wrapped with M-q. It seems to affect the description of the org link to escape the spaces. I'm not sure what effect this has on export. From what Tom is saying it isn't unescaping the text. Regards, Jon > > Regards, > > -- > Nicolas Goaziou
Re: [O] latex code block evaluation
Hi Sebastien, "Sebastien Vauban" writes: > Hi Henry, > > henry atting wrote: >> I have this latex code block: >> >> #+begin_src latex :file foo.pdf >> \documentclass{article} >> \begin{document} >> ...some text... >> \end{document} >> #+end_src >> >> After evaluation the resulting file looks like this: >> >> article ...some text... >> >> I do not understand this. As far as I know it is possible to define the >> latex documentclass within a code block. > > Could you be more explicit? Do you want to use that to pass parameters to the > LaTeX backend? If yes, why not using the "#+LaTeX:" directive (not sure > they're still supported with the exact same syntax as before -- I've not yet > merged my documents). And that brings us to the most important question: old > or new exporter? > > Eventually, can you send a real ECM, or your real use case? Ah, I see, I was unclear. In this case I simply want to evalutate this code block with `C-c C-c'. I do not use the orgmode LaTeX exporter, only the HTML exporter. Finally I will create org files with LaTeX code blocks which I will export to HTML. And that's all. HTML export works fine with the old or the new exporter. Though in this case it is not really indispensable I only was wondering why code block evalution does not work as expected. Why is `\documentclass{article}' not recognized properly? > Best regards, > Seb Greetings, henry
Re: [O] OT, but not really: todays XKCD
"Dominik, Carsten" writes: > Hurray for Nicolas and Bastien to be brave and switch to the > new exporter framework which is a thing of beauty. It is an umbrella statement and doesn't mean much in and of itself. Let me clarify, Bastien has very miniscule (~ZERO) contribution to the new framework or the exporters. I was forced to respond because your mail will be read by many. People tend to impose their own meanings in to statements. IMNSHO, clubbing Nicolas work with Bastien, is doing Nicolas a big dis-service and giving Bastien "an association" that he doesn't deserve. I will also encourage people who donate to Orgmode - particularly those who will be donating for impending Org-8.0 release - to make targeted donations to Nicolas Goaziou (exclusively) or take his advise on how the funds should be routed (if he is averse to taking donations). A targeted donation (for individual work or hosting the servers) is much better than an umbrella donation to Orgmode or Bastien. Let's share good will and credit where it is due and NOT give credit when nothing is due. This is important when one is respected, trusted and is in position of some influence. I am particularly worried to see recent call for donations on Google+ which raised to the pitch to that of religious fundraising. ps-1: I have openly stated that I have no interest in partaking of or seeking donations for Emacs/Orgmode related work. I consider my existing work as a donation themselves. --
[O] OT, but not really: todays XKCD
Hi everyone. I am sorry for the spam, but todays XKCD http://xkcd.com/1172/ is just too good to not share here, together with this piece of data: $ grep defcustom lisp/*el contrib/lisp/*el |wc -l 1213 Hurray for Nicolas and Bastien to be brave and switch to the new exporter framework which is a thing of beauty. Lets help them to fix the bugs as quickly as possible and then make those small adaptations in our workflow - it will be worth it. - Carsten
[O] org-fill-paragraph breaks timestamps
Hi list, In plain lists, I sometimes insert timestamps in running text (for an item to appear in the agenda), then fill it with org-fill-paragraph. Sometimes, the timestamp is splitted (at any of both spaces), breaking the desired agenda behavior. Is there something I can do for this not to happen ? I guess the filling function should recognize the timestamp not to split it, but my lisp knowledge makes it more of a feature request than anything else. -- William (Like so : <2013-02-09 Sat 14:46>)