[O] Bug: performance of scrolling in large example blocks is poor
Testcase: 1 megabyte of text lines in an example block, drag the scrollbar to a location you haven't been to yet. It often freezes for a few seconds, and doing things while its frozen like scrolling more can quickly make it freeze for a minute or so. Remove the example block enclosure, and it becomes totally interactive. - Ian
[O] syntax highlighting works on all BUT R statistics
Hi all I have a weird issue. i can get syntax highlighting working on all code blocks (Python,elisp,ruby etc) BUT R statistics highlighting dosent work. below is my config entry for org-babel-load-languages. thanks alot Z #+begin_src emacs-lisp results none ; And add babel inline code execution ; babel, for executing code in org-mode. (org-babel-do-load-languages 'org-babel-load-languages ; load all language marked with (lang . t). '((C . t) (R . t) (asymptote) (awk) (calc) (clojure) (comint) (css) (ditaa . t) (dot . t) (emacs-lisp . t) (fortran) (gnuplot . t) (haskell) (io) (java) (js) (latex) (ledger) (lilypond) (lisp) (matlab) (maxima) (mscgen) (ocaml) (octave) (org . t) (perl) (picolisp) (plantuml) (python . t) (ref) (ruby) (sass) (scala) (scheme) (screen) (sh . t) (shen) (sql) (sqlite))) #+end_src
[O] Org is awesome
After 243 commits to a constellation of org files, producing 10849 lines of LaTeX code from the Beamer exporter, which render into 229 pages of beamerarticle print-ready material, including 156 captioned code listings (and a handful of un-numbered ones) and 27 pages of fully indexed glossary entries (whose LaTeX code comes from emacs-lisp source blocks processing org tables), I think I'm in a position to state with confidence: ORG IS AWESOME. "Thanks to all the developers" is insufficient. hjh
[O] stderr patch
I use babel mostly for shell scripts. I wrote a patch to allow toggling the handling of errors & std err. I prefer standard error just get printed with everything else, the same as calling a script from a terminal. Doing this properly with header arguments etc. has been discussed before (google org-babel stderr), and just hasn't gotten done yet. Until then, this works great, so I'm putting it out there in case anyone wants to use it. --- lisp/ob-eval.el | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el index 057590f..fdc6da5 100644 --- a/lisp/ob-eval.el +++ b/lisp/ob-eval.el @@ -31,6 +31,14 @@ (eval-when-compile (require 'cl)) (defvar org-babel-error-buffer-name "*Org-Babel Error Output*") +(defcustom org-babel-use-error-buffer t + "When evaluating a code block, if nil and an error is returned +,no error buffer is created and. Standard error +is redirected to standard out." +:group 'org-babel +:version "24.1" +:type 'boolean) + (declare-function org-babel-temp-file "ob-core" (prefix &optional suffix)) (defun org-babel-eval-error-notify (exit-code stderr) @@ -46,14 +54,16 @@ "Run CMD on BODY. If CMD succeeds then return its results, otherwise display STDERR with `org-babel-eval-error-notify'." - (let ((err-buff (get-buffer-create " *Org-Babel Error*")) exit-code) -(with-current-buffer err-buff (erase-buffer)) + (let ((err-buff (if org-babel-use-error-buffer + (get-buffer-create " *Org-Babel Error*"))) + exit-code) +(if err-buff (with-current-buffer err-buff (erase-buffer))) (with-temp-buffer (insert body) (setq exit-code (org-babel--shell-command-on-region (point-min) (point-max) cmd err-buff)) - (if (or (not (numberp exit-code)) (> exit-code 0)) + (if (and err-buff (or (not (numberp exit-code)) (> exit-code 0))) (progn (with-current-buffer err-buff (org-babel-eval-error-notify exit-code (buffer-string))) @@ -90,7 +100,7 @@ function in various versions of Emacs. ;; This is fixed in Emacs trunk as of 2012-12-21; let's use this ;; workaround for now. (unless (file-remote-p default-directory) - (delete-file error-file)) + (if error-file (delete-file error-file))) ;; we always call this with 'replace, remove conditional ;; Replace specified region with output from command. (let ((swap (< start end))) -- 1.7.10.4
Re: [O] #+HOMEPAGE in metadata - feature request?
Marcin Borkowski writes: > Dnia 2014-03-22, o godz. 00:44:40 > Bastien napisał(a): > >> Hi Marcin, >> >> Marcin Borkowski writes: >> >> > So the problem is: it would be (imho) useful to have a "homepage" >> > added to general metadata, but it is not clear how to translate >> > this to e.g. LaTeX's (rather ancient) concept of metadata. >> > (Interestingly, some other classes, e.g. memoir, koma-script and >> > titlepage, also do not seem to cater for this need. I'm going to >> > ask on TeX.SE if there's any class/package enabling putting a url >> > on the titlepage...) So while (I assume) adding a #+HOMEPAGE >> > field/option in Org would be easy, it is not obvious how to render >> > it for different exporters. >> >> Thanks for the explanations, I get it now; but unless I'm really tired >> (could be), you only mention backends that do not support a concept of >> "homepage"... right? > > Right. I did not really use other backends; what drives my suggestion > is a /need/ for a url in the titlepage, not an /existence/ of such > feature in other tools. (It would be hard for me to believe that I'm > the only one needing this, btw...) > For latex, the ams classes (amsart, etc) provide a \urladdr macro. I imagine something similar could be easily added to the standard classes. Or you can cheat: #+AUTHOR: #+LATEX_HEADER: \author{A.U.Thor\thanks{http://www.foo.org} -- Nick
Re: [O] Bug (?): export to markdown - toc in html
Dnia 2014-03-22, o godz. 01:00:58 Bastien napisał(a): > Hi Marcin, > > Marcin Borkowski writes: > > > export to markdown has a strange problem. Before the markdown > > contents, I get a ToC in HTML. #+OPTIONS: toc:nil disables that, > > but I guess it shouldn't be needed. > > I guess that's on purpose, since you can use HTML in markdown. > If you don't want the toc in that case, using toc:nil is the way > to go... I see. So it's a feature, not a bug;). Good to know, I'll just disable ToC then. Thanks, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] #+HOMEPAGE in metadata - feature request?
Dnia 2014-03-22, o godz. 00:44:40 Bastien napisał(a): > Hi Marcin, > > Marcin Borkowski writes: > > > So the problem is: it would be (imho) useful to have a "homepage" > > added to general metadata, but it is not clear how to translate > > this to e.g. LaTeX's (rather ancient) concept of metadata. > > (Interestingly, some other classes, e.g. memoir, koma-script and > > titlepage, also do not seem to cater for this need. I'm going to > > ask on TeX.SE if there's any class/package enabling putting a url > > on the titlepage...) So while (I assume) adding a #+HOMEPAGE > > field/option in Org would be easy, it is not obvious how to render > > it for different exporters. > > Thanks for the explanations, I get it now; but unless I'm really tired > (could be), you only mention backends that do not support a concept of > "homepage"... right? Right. I did not really use other backends; what drives my suggestion is a /need/ for a url in the titlepage, not an /existence/ of such feature in other tools. (It would be hard for me to believe that I'm the only one needing this, btw...) > There is #+HTML_LINK_HOME in the ox-rss.el backend to specify a link > to the homepage (different from the baseurl, since you don't want to > use a baseurl in a RSS feed.) So maybe that's a start. I see. I'll look into this tomorrow. Thanks, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] [bug] [babel] babel corrupts undo history
here is the fix for bug #3: change this line in org-src.el (let ((buffer-undo-list t)) to: ;; don't change my undo list here, please (progn this fixes the problem. i really don't think this kind of fancy undo list manipulation is the right thing to do in org. On 3/21/14, Samuel Wales wrote: > bug #3: > > insert a source block > edit after it > c-c ' to edit > edit > c-c ' to go back to mybuffer > edit before the source block > undo > undo > > you should notice that the source block is not restored. > > note that this is not the same buffer corruption issue i reported > previously. > > in that one, you insert a source block, fill it, and undo. then the > next header line gets corrupted: > > bug #2: > > * header > #+begin_src org > asdf > asdf > #+end_src > * header2 > > put point inside the source block, fill, then undo. you will see > buffer corruption after the source block. the exact corruption > varies. sometimes it is removal of the #. other times it is removal > of * in 1 or 2 headlines below. > > what makes it much worse is that you cannot undo to fix the buffer > corruption. you have to revert the buffer. > > there are others. i believe the reason is that org tries to get fancy > with undo. > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] [bug] [babel] babel corrupts undo history
bug #3: insert a source block edit after it c-c ' to edit edit c-c ' to go back to mybuffer edit before the source block undo undo you should notice that the source block is not restored. note that this is not the same buffer corruption issue i reported previously. in that one, you insert a source block, fill it, and undo. then the next header line gets corrupted: bug #2: * header #+begin_src org asdf asdf #+end_src * header2 put point inside the source block, fill, then undo. you will see buffer corruption after the source block. the exact corruption varies. sometimes it is removal of the #. other times it is removal of * in 1 or 2 headlines below. what makes it much worse is that you cannot undo to fix the buffer corruption. you have to revert the buffer. there are others. i believe the reason is that org tries to get fancy with undo.
Re: [O] [bug] [babel] babel corrupts undo history
Samuel Wales writes: > in other words, if b consists of editing a source block, then i > /still/ expect b to be undone, because the contents of that source > block are part of mybuffer.org. I think we are miscommunicating... I simply say that I cannot reproduce the bug: for me, when b consists of editing a source block, b can be undone. At this point, I think the only way out is to have someone else reproduce the bug too, otherwise we may miscommunicate for way too long :) -- Bastien
Re: [O] org-export-format-source-code-or-example: End of Buffer
Hi Mishal, Mishal Awadah writes: > I’m having a problem with org-mode source blocks in python when > python-mode.el is enabled for python-mode instead of python.el. > > I detailed my problem here: http://stackoverflow.com/questions/ > 22565379/ > emacs-org-mode-python-source-blocks-dont-export-with-python-mode-el > > and it looks like there is some history with a now non-existant > function org-html-do-format-code here: http://lists.gnu.org/archive/ > html/emacs-orgmode/2014-03/msg01018.html Be reassured, `org-html-do-format-code' still exists! I can't reproduce the problem: I installed python-mode.el from launchpad and tried to export a file containing some python code to HTML, it exports well. Can you share a minimal example? Thanks, -- Bastien
Re: [O] [bug] [babel] babel corrupts undo history
On 3/21/14, Bastien wrote: > The changes happen in different buffers, there is no reason to > expect undo to let you undo changes you made from another buffer. you might be surprised to find that i disagree. :] let's concentrate on just one aspect of this. i believe that most users expect that all changes to a buffer are reflected in the undo list. if i am in mybuffer.org, and i make these changes: a b c and i undo, i expect c b a. i do NOT expect c a. that is disconcerting and surprising. in other words, if b consists of editing a source block, then i /still/ expect b to be undone, because the contents of that source block are part of mybuffer.org. those contents are plain text in mybuffer.org. perhaps you think of an org document as being a framework inside of which is foreign material that should be skipped over in undo? i do not. i think of it as plain text that should be undoable. this is just one aspect of it.
Re: [O] Bug (?): export to markdown - toc in html
Hi Marcin, Marcin Borkowski writes: > export to markdown has a strange problem. Before the markdown > contents, I get a ToC in HTML. #+OPTIONS: toc:nil disables that, but I > guess it shouldn't be needed. I guess that's on purpose, since you can use HTML in markdown. If you don't want the toc in that case, using toc:nil is the way to go... -- Bastien
Re: [O] Navigating from agenda causes incorrect expansion of children
I think I see what you mean but it's hard to implement. The only way to fix this is to discuss the default value for org-show-* properties (and maybe some others) -- if you have suggestions here with examples on how different defaults would be less confusing, let's discuss this specifically. In the meantime, relevant hooks may be difficult to explore but we fix this by replying to questions here and but adding information in the manual when needed -- doc bug reports and patches are welcome. Or even better, a tutorial exploring all things relating to "visibility and revealing" in Org. -- Bastien
Re: [O] #+HOMEPAGE in metadata - feature request?
Hi Marcin, Marcin Borkowski writes: > So the problem is: it would be (imho) useful to have a "homepage" added > to general metadata, but it is not clear how to translate this to e.g. > LaTeX's (rather ancient) concept of metadata. (Interestingly, some > other classes, e.g. memoir, koma-script and titlepage, also do not seem > to cater for this need. I'm going to ask on TeX.SE if there's any > class/package enabling putting a url on the titlepage...) So while (I > assume) adding a #+HOMEPAGE field/option in Org would be easy, it is > not obvious how to render it for different exporters. Thanks for the explanations, I get it now; but unless I'm really tired (could be), you only mention backends that do not support a concept of "homepage"... right? There is #+HTML_LINK_HOME in the ox-rss.el backend to specify a link to the homepage (different from the baseurl, since you don't want to use a baseurl in a RSS feed.) So maybe that's a start. -- Bastien
Re: [O] [bug] [babel] babel corrupts undo history
Hi Samuel, Samuel Wales writes: > c-c ' > edit > c-c ' > edit > undo > undo OOPS the source edit is skipped over what just happened? > c-c ' > undo OOPS the undo changes are all gone where did they go? The changes happen in different buffers, there is no reason to expect undo to let you undo changes you made from another buffer. Or is it something something you see elsewhere in Emacs? Agenda undo is different: manipulations in the agenda modify the source buffer, so undo in the agenda should undo in the source buffer. In *Org Src*, manipulation are reflected in the source buffer only when you save the *Org Src* buffer or when you exit it. When you save, you can undo in the *Org Src* buffer, and changes will be be reflected in the source buffer at the time you exit the temporary buffer. When you exit the buffer, there is no undo problem left. > and at worst there is buffer corruption. Sorry to ask it again, but please let me know about a reprocible recipe, I could not reproduce the problem you have. > it is much better to not skip an entire set of changes + no bugs than > "the user will never want to see the indentation adding so let's > pretend it doesn't exist". That's not my reasoning, which is "undo applies to manual changes. -- Bastien
Re: [O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Hi Konstantin, Konstantin Kliakhandler writes: > It appears that org-mode produces invalid latex code. An example > follows. Fixed, thanks, -- Bastien
Re: [O] Navigating from agenda causes incorrect expansion of children
i am saying that i prefer [and i believe new users will often prefer] that org not hide things unless they are just normal folding. this preference is currently impossible to convey to org. === more details: i do not ever want to see only the first headline of a set of headlines, for example. it is too confusing to think that that is the only headline. it is too troublesome to have to go to the parent and cycle twice just to show the headlines. this default is one of several that i want to erase. and yet it is the default behavior and cannot be fixed without defadvice and hooks and so on. and i still have a whole bunch of issues like this that after many years i still have not been able to fix. === canonical = "what i can in principle reproduce with tab and arrows". showing only the first child [for example] CANNOT be produced with tab and arrows, ergo it is not canonical. try it and see -- you can't make org hide the remaining children. the problem is that there is no variable in org that specifies to org "i don't like that behavior or any behavior like that behavior". [this is only one of several examples where there are strange ellipses and strange sparse-tree-like hiding.] === so i am saying a variable that says "i only ever want canonical visibility" would be a great idea. On 3/21/14, Bastien wrote: > Samuel Wales writes: > >> as for org contexts, perhaps we need something like an >> org-show-canonical-form, where canonical form is a state of visibility >> that can be created from a folded org file using TAB and arrow keys >> alone. > > You mean `org-reveal' should depend on the some hardcoded visibility > property rather on the user preferences? I'm not sure I completely > grok what you refer to here, sorry. > > -- > Bastien > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] [bug] [babel] babel corrupts undo history
s/most cases/all cases that i am aware of/ On 3/21/14, Samuel Wales wrote: > in most cases, i think the undo list manipulation should never happen > in the first place. it just causes too many problems.
Re: [O] [bug] [babel] babel corrupts undo history
hi bastien, On 3/21/14, Bastien wrote: >> buffer will be corrupted. > > Not for me. This has surely to do with undo-tree. in emacs 23, i get the same bug with built-in undo. >> one thing org sometimes does is try to set buffer-undo-list. it's >> really for speed imo. i can't think of any reason why org really >> needs it. perhaps i am mistaken and there is a really good reason for >> such things, but i suspect it has caused a lot of bugs. > > I can safely say this is *never* for speeding things up, it's for > preserving the undo list state. no, you misunderstand. there is no sufficiently good reason for org code to ever set such an internal variable in any buffer that the user edits to my knowledge. the only reason that makes sense to me is to turn off undo by setting it to t in buffers that the user does not edit [such as a hidden buffer], so that you avoid possible overhead. that /is/ a potential speed issue, even if it is mediated by memory. thus, in practice, the variable is only really best used for speed imo. > Unless I misunderstand, the addition of indentation is not manually > done, so it should not be part of the undo list. you understand here i think, but we disagree. at present org manipulates an undo variable that should not be manipulated, and the result at best is that the user does this: c-c ' edit c-c ' edit undo undo OOPS the source edit is skipped over what just happened? c-c ' undo OOPS the undo changes are all gone where did they go? and at worst there is buffer corruption. so i would far prefer to have the indentation adding be NOT specially worked around by changing the undo variable. it is much better to not skip an entire set of changes + no bugs than "the user will never want to see the indentation adding so let's pretend it doesn't exist". it might be better to have no indentation by default, but that's another issue. >> even when there is not a bug per se, when you edit a source block, >> there is a gap in the undo record. like nixon's tape gap during >> watergate, it raises questions. :/ > > :) principle of least surprise is key here. >> to me, undo is a low-level feature that should never be buggy or >> surprising. if it is, then anything that causes those should be >> ripped out, even if it means losing a fancy undo-related feature. > > Fully agreed. Let's raise bugs in this area when you have time > and when the bug can be isolated from other third-part package. i haven't tried with -Q yet but i don't think it's an undo-tree bug. i think fixing each bug as it comes up is more error-prone for the future than stopping the changing of undo-tree-list. in most cases, i think the undo list manipulation should never happen in the first place. it just causes too many problems. samuel
Re: [O] org-export-latex-hyperref-options-format
t...@tsdye.com (Thomas S. Dye) writes: > Aloha Nick, > > Nick Dokos writes: > >> #+BIND is supposed to bind the variable *during export*. The test is to >> run the export and see if the hyperref stuff is gone from the tex file. >> >> Nick > > I did run the export and the hyperref stuff was still in the tex file. > > I'm exporting asynchronously--perhaps that's the problem? The old > #+OPTIONS: texht:nil worked for asynchronous export, though, so I was > expecting that BIND would do the same. > I tried both with and without async (deleting the tex file before starting each time - I also used the default latex class, since I don't have plos-devel): either way the hyperref stuff was gone. Here's the org file: --8<---cut here---start->8--- #+TITLE: Structure and Growth of the Leeward Kohala Field System: An Analysis with Directed Graphs #+DATE: #+LANGUAGE: en #+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t ':t ^:{} #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:nil pri:nil tags:not-in-toc #+BIND: org-latex-hyperref-template "" #+STARTUP: entitiespretty #+PROPERTY: header-args:sh :eval no-export * foo bar --8<---cut here---end--->8--- Org-mode version 8.2.5h (release_8.2.5h-782-g040ec4 @ /home/nick/elisp/org-mode/lisp/) Nick
Re: [O] org-export-latex-hyperref-options-format
Thomas, Thomas S. Dye wrote: Aloha Nick, Nick Dokos writes: #+BIND is supposed to bind the variable *during export*. The test is to run the export and see if the hyperref stuff is gone from the tex file. Nick I did run the export and the hyperref stuff was still in the tex file. I'm exporting asynchronously--perhaps that's the problem? The old #+OPTIONS: texht:nil worked for asynchronous export, though, so I was expecting that BIND would do the same. I guess I could set org-export-hyperref-template to "" in the asynchronous export initialization file ... All the best, Tom Nick pointed out this thread to me when I had a similar (or the same) problem. I changed the hyperref template to the empty string. http://thread.gmane.org/gmane.emacs.orgmode/82430 Charlie Millar
Re: [O] Navigating from agenda causes incorrect expansion of children
Samuel Wales writes: > as for org contexts, perhaps we need something like an > org-show-canonical-form, where canonical form is a state of visibility > that can be created from a folded org file using TAB and arrow keys > alone. You mean `org-reveal' should depend on the some hardcoded visibility property rather on the user preferences? I'm not sure I completely grok what you refer to here, sorry. -- Bastien
Re: [O] [bug] [babel] babel corrupts undo history
Hi Samuel, Samuel Wales writes: > typical example of last one: > > === > * bastien > #+begin_src org > bastien > ^bastien > #+end_src > * bastien > === > > put point at ^, fill-paragraph, undo. with undo-tree, at least, the > buffer will be corrupted. Not for me. This has surely to do with undo-tree. > one thing org sometimes does is try to set buffer-undo-list. it's > really for speed imo. i can't think of any reason why org really > needs it. perhaps i am mistaken and there is a really good reason for > such things, but i suspect it has caused a lot of bugs. I can safely say this is *never* for speeding things up, it's for preserving the undo list state. > in the case of c-c ', i would prefer having the indentation adding > show up as an undo entry [or whatever would happen if we ripped out > the undo-related setting]. Unless I misunderstand, the addition of indentation is not manually done, so it should not be part of the undo list. > even when there is not a bug per se, when you edit a source block, > there is a gap in the undo record. like nixon's tape gap during > watergate, it raises questions. :/ :) > to me, undo is a low-level feature that should never be buggy or > surprising. if it is, then anything that causes those should be > ripped out, even if it means losing a fancy undo-related feature. Fully agreed. Let's raise bugs in this area when you have time and when the bug can be isolated from other third-part package. Maybe that's me not being able to reproduce the ones you mention, but other people can chime in too, if the bug is real. Thanks! -- Bastien
Re: [O] Problem with org-bibtex-read with fields type, key
"Stefan-W. Hahn" writes: > I will get into it and try to make a proposal. Thanks in advance! -- Bastien
[O] Bug (?): export to markdown - toc in html
Hi all, export to markdown has a strange problem. Before the markdown contents, I get a ToC in HTML. #+OPTIONS: toc:nil disables that, but I guess it shouldn't be needed. Org-mode version 8.2.5f (8.2.5f-elpa @ /home/marcin/.emacs.d/elpa/org-20140116/) Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] org-export-latex-hyperref-options-format
Aloha Nick, Nick Dokos writes: > #+BIND is supposed to bind the variable *during export*. The test is to > run the export and see if the hyperref stuff is gone from the tex file. > > Nick I did run the export and the hyperref stuff was still in the tex file. I'm exporting asynchronously--perhaps that's the problem? The old #+OPTIONS: texht:nil worked for asynchronous export, though, so I was expecting that BIND would do the same. I guess I could set org-export-hyperref-template to "" in the asynchronous export initialization file ... All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [POLL] Do you need special entities in radio target?
imo radio targets are fundamentally limited because they only work in the same file, while org has become a multi-file mode. i am ok with cosmetic limitations in addition. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
[O] [POLL] Do you need special entities in radio target?
Hi all, the subject says it all -- see this thread for reference: http://thread.gmane.org/gmane.emacs.orgmode/83648 Would you be okay if radio targets like <<>> are limited to plain text? Thanks for your feedback, -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Noah Slater writes: > Or perhaps to survey what is already out there. What are people > already doing/trying to do? I opened a different thread to make the poll more prominent. -- Bastien
Re: [O] [bug] [babel] babel corrupts undo history
hi bastien, thanks for revisiting this. i cannot do thorough bug reports at this time, but there are a few undo-related issues in org-mode now. here are a few from memory [there are others]: - occasional buffer or undo-tree corruption from c-c ' [see previous posts in this thread] - disruptive and surprising combining of undo entries when doing agenda operations where you can't undo properly - buffer corruption without c-c ' typical example of last one: === * bastien #+begin_src org bastien ^bastien #+end_src * bastien === put point at ^, fill-paragraph, undo. with undo-tree, at least, the buffer will be corrupted. === often there is no way to fix the buffer corruption. undo is after all a way to fix things. so i'm particularly sensitive to it not working. if org did not touch undo internal features, then i think undo would be more trustworthy. this is what i prefer as a user. i think not touching undo internals is the safer, more defensive strategy. === one thing org sometimes does is try to set buffer-undo-list. it's really for speed imo. i can't think of any reason why org really needs it. perhaps i am mistaken and there is a really good reason for such things, but i suspect it has caused a lot of bugs. in the case of c-c ', i would prefer having the indentation adding show up as an undo entry [or whatever would happen if we ripped out the undo-related setting]. separating the undo of the base and indirect buffers leads to surprises. i expect undo to just work in both places and not to undo things that i did not edit last. even when there is not a bug per se, when you edit a source block, there is a gap in the undo record. like nixon's tape gap during watergate, it raises questions. :/ === to me, undo is a low-level feature that should never be buggy or surprising. if it is, then anything that causes those should be ripped out, even if it means losing a fancy undo-related feature. for me, the best undo feature of all is reliability. :] samuel On 3/18/14, Bastien wrote: > Hi Samuel, > > Samuel Wales writes: > >> as far as i know, my assessment below is correct, but i cannot >> confirm. > > I revisited this thread. > >> i believe that if undo-related code is ripped out of babel, then undo >> will work correctly in the source buffer and in the edit buffer. >> i am not clear on what the purpose of changing undo behavior is? > > Time flies: maybe it was clear before, but for now undo works fine > for me, in the source editing buffer and in the original buffer too. > > When I do C-c ' from the *Org Src* buffer, then C-/, the buffer is > restored to its previous state, that is: before the insertion of the > edited source. > > Can you restate what the bug is? > > Thanks, > > -- > Bastien > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Navigating from agenda causes incorrect expansion of children
On 3/20/14, Bastien wrote: >> my strong intuition says that it calls for a global solution rather >> than patching each one as it comes up. > > There is this bug report I made recently: > http://comments.gmane.org/gmane.emacs.bugs/83721 interesting. these topics are worth looking at. as for org contexts, perhaps we need something like an org-show-canonical-form, where canonical form is a state of visibility that can be created from a folded org file using TAB and arrow keys alone. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] org-export-latex-hyperref-options-format
t...@tsdye.com (Thomas S. Dye) writes: > Nicolas Goaziou writes: > >>> If not, can someone offer advice on the best way to set >>> org-latex-hyperref-template to achieve the same file-local effect? >> >> Assuming `org-export-allow-bind-keywords' is non-nil, does >> >> #+BIND: org-latex-hyperref-template "" >> >> work? > > I can't get this to work. > > Here is the top of my Org mode file: > > #+TITLE: Structure and Growth of the Leeward Kohala Field System: An > Analysis with Directed Graphs > #+DATE: > #+LANGUAGE: en > #+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t ':t > ^:{} > #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:nil pri:nil tags:not-in-toc > #+BIND: org-latex-hyperref-template "" > #+LATEX_CLASS: plos-devel > #+STARTUP: entitiespretty > #+PROPERTY: header-args:sh :eval no-export > > The variable org-export-allow-bind-keywords is t. > > When I open this file and ask for information about > org-latex-hyperref-template, I get this: > > org-latex-hyperref-template is a variable defined in `ox-latex.el'. > Its value is > "\\hypersetup{\n pdfkeywords={%k},\n pdfsubject={%d},\n > pdfcreator={%c}}\n" > > Org-mode version 8.2.5h (release_8.2.5h-757-gc444e4 @ > /Users/dk/.emacs.d/src/org-mode/lisp/) > #+BIND is supposed to bind the variable *during export*. The test is to run the export and see if the hyperref stuff is gone from the tex file. Nick
Re: [O] #+HOMEPAGE in metadata - feature request?
Dnia 2014-03-21, o godz. 14:07:58 Bastien napisał(a): > Hi Marcin, > > Marcin Borkowski writes: > > > what about adding #+HOMEPAGE (alongside #+AUTHOR and #+EMAIL) to the > > metadata? > > What would it do? > > > What are the pros and cons? (One argument against: default > > LaTeX classes do not support this. Any other?) > > Not sure what "supporting" means :) OK, I was too vague - sorry. What I mean is that quite often you want to include some kind of web page in the titlepage, be it a LaTeX book/textbook/manual, Beamer or reveal.js presentation etc. The problem is, LaTeX does not have a syntax for this (it is too old for that, apparently...). Interestingly, Beamer doesn't have anything for that, either. In org-reveal, however, the "author" and "email" are just generic 's (in fact, I fixed it in my config by adding them a "titlepage" class, so that they can be different from 's on regular slides). So the problem is: it would be (imho) useful to have a "homepage" added to general metadata, but it is not clear how to translate this to e.g. LaTeX's (rather ancient) concept of metadata. (Interestingly, some other classes, e.g. memoir, koma-script and titlepage, also do not seem to cater for this need. I'm going to ask on TeX.SE if there's any class/package enabling putting a url on the titlepage...) So while (I assume) adding a #+HOMEPAGE field/option in Org would be easy, it is not obvious how to render it for different exporters. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
[O] Bug: \uline produced inside \section in latex export [8.2.5h (8.2.5h-30-gdd810b-elpa @ /home/user/.emacs.d/elpa/org-20140303/)]
Hello, It appears that org-mode produces invalid latex code. An example follows. Best, Kosta Insert the following example text into an org buffer: === * _Example Text_ === Then export as latex. The following is produced: === % Created 2014-03-21 Fri 17:45 \documentclass[11pt]{article} \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage{fixltx2e} \usepackage{graphicx} \usepackage{longtable} \usepackage{float} \usepackage{wrapfig} \usepackage{rotating} \usepackage[normalem]{ulem} \usepackage{amsmath} \usepackage{textcomp} \usepackage{marvosym} \usepackage{wasysym} \usepackage{amssymb} \usepackage{hyperref} \tolerance=1000 \author{Author Name} \date{\today} \title{org-bug.org} \hypersetup{ pdfkeywords={}, pdfsubject={}, pdfcreator={Emacs 24.3.50.1 (Org mode 8.2.5h)}} \begin{document} \maketitle \tableofcontents \section{\uline{Example Text}} \label{sec-1} % Emacs 24.3.50.1 (Org mode 8.2.5h) \end{document} === It appears that \uline inside \section is invalid. pdflatex output follows: === Running `LaTeX' on `org-test' with ``pdflatex --synctex=1 -interaction=nonstopmode "\input" org-test.tex'' This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Debian) restricted \write18 enabled. entering extended mode LaTeX2e <2011/06/27> Babel and hyphenation patterns for english, dumylang, nohyphenation, loaded. (./org-test.tex (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls Document Class: article 2007/10/19 v1.4h Standard LaTeX document class (/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo)) (/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty (/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def (/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu) (/usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu) (/usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu))) (/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty (/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def)) (/usr/share/texlive/texmf-dist/tex/latex/base/fixltx2e.sty) (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty) (/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty (/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty) (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/graphics.cfg) (/usr/share/texlive/texmf-dist/tex/latex/pdftex-def/pdftex.def (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty (/usr/share/texlive/texmf-dist/tex/latex/tools/longtable.sty) (/usr/share/texlive/texmf-dist/tex/latex/float/float.sty) (/usr/share/texlive/texmf-dist/tex/latex/wrapfig/wrapfig.sty) (/usr/share/texlive/texmf-dist/tex/latex/rotating/rotating.sty (/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty)) (/usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty) (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty For additional information on amsmath, use the `?' option. (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty)) (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty) (/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty)) (/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty (/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.def (/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.dfu))) (/usr/share/texlive/texmf-dist/tex/latex/marvosym/marvosym.sty) (/usr/share/texlive/texmf-dist/tex/latex/wasysym/wasysym.sty) (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty)) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty)) (/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty) (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def) (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/hyperref.cfg) (/usr/share/texlive/texmf-dist/tex/latex/url/url.sty)) Package hyperref Message: Driver (autodetected): hpdftex. (/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty)) (./org-test.aux) (/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd) (/usr/share/texlive/texmf-dist/tex/context/base/supp-pdf.mkii [Loading MPS to PDF converter (version 2006.09.02).] ) (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty) (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg)) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/gettitlestring.sty)) (./org-test.out) (./org-test.out) (/usr/share/texlive/texmf-d
[O] bug#17055: 24.3.50; Emacs hangs in Org mode file
Bastien wrote: > Eli Zaretskii writes: > >> I hope Org maintainers could take a good look on this. > > Yes, I think Nicolas is on it. > > Speaking of that, this is one of the few remaining bugs > we want to fix before 8.2.3, I hope we will have time to > merge 8.2.3 into the emacs-24 branch then. Regarding the "few remaining bugs we want to fix" part, I'd advocate trying to solve the following 2 bugs as well before merging back into Emacs: - #16440: Some colors of the theme aren't respected in latest Emacs - #15298: Background color lost when highlighting a string Best regards, Seb -- Sebastien Vauban
Re: [O] Problem with org-bibtex-read with fields type, key
Mail von Bastien, Wed, 19 Mar 2014 at 12:08:47 +0100: Hello Bastian, > Yes, I confirm the bug -- by any chance, did you have time to > sort this out? (I see you already committed a fix to org-bibtex.el) sorry, just saw your reply. I will get into it and try to make a proposal. With kind regards, Stefan -- Stefan-W. Hahn It is easy to make things. It is hard to make things simple.
Re: [O] org-agenda-do-date-late and emacs freeze
Bastien writes: > Hi Matt and all, > > thanks a lot for the detailed investigation -- I revisited the > related problems and applied a fix. Please let me know if you > encoutner some glitches. Seems to work fine now. Thanks! Matt
Re: [O] org-element checks make flyspell prohibitively slow
Hi Nicolas, Nicolas Goaziou writes: > Matt Lundin writes: > >> The rewrite of org-mode-flyspell-verify in commit >> 4a27c2b4b67201e0b23f431bdaeb6460b31e1394 (Nov 21, 2013) makes navigating >> org-mode files with large chunks of text very slow. > > [...] > >> => Org-mode version 8.2.5h (release_8.2.5h-757-gc444e4 @ >> /home/matt/org-mode/lisp/) > > Could you update and try again? Parser's cache was inadvertently > disabled. I re-enabled it. Yes, I can confirm that it is faster now. Thanks. >> core/acl 2.2.52-2 [installed] >> Access control list utilities, libraries and headers >> core/archlinux-keyring 20140220-1 [installed] >> Arch Linux PGP keyring >> core/attr 2.4.47-1 [installed] >> Extended attribute support library for ACL support >> core/autoconf 2.69-1 (base-devel) [installed] >> A GNU tool for automatically configuring source code >> core/automake 1.14.1-1 (base-devel) [installed] >> A GNU tool for automatically creating Makefiles >> >> All in all, it's 12680 lines > > Note that it is a contrived example: the whole buffer is a single > paragraph containing around 150 objects. The current algorithm for > `org-element-context' is clearly not on par with such a density of > objects per paragraph. Yes, it is indeed a contrived example. I originally thought I had a use for it --- i.e., analyzing the packages I had installed --- but soon realized that such a task is better accomplished in a separate text file. > Also, cache cannot help here, because each time you edit a paragraph, > all objects within are removed from the cache (because, AFAIK, there > is no way to know if the edition altered a previously parsed object or > not, so, as a security measure, all of them are wiped out) and you > have to parse them again. > > Therefore, navigation should be fast but editing (with flyspell-mode > enabled) is going to be slow. Good to know. Thanks again! Matt
Re: [O] Out of Order Evaluation
On Mar 20, 2014, at 21:34, Charles Berry wrote: > Andreas Leha med.uni-goettingen.de> writes: > >> >> Hi Michael, >> >> Michael Weylandt gmail.com> writes: >> >>> Hi, >>> >>> I want to put a summary of my analysis at the beginning of a document >>> using results calculated at the end of the document. Is this possible? > > [snip] > >>> >>> Is this possible in a single pass? > > > Not quite. The method suggested by Andreas computes the result twice. If > there is any randomness in the results (as in the example) you will get a > different answer in the summary than when the block is later evaluated. > >>> I've played with #+NAME and >>> <> but haven't gotten the out-of-order evaluation quite >>> right. > > You can use > > #+results: the-mean > > before > > #+NAME: the-mean > #+begin_src R > mean(x) > #+end_src > > which is after 'theanalysis' block. > > And if the format is not pleasing add a filter that reformats the results Great. The named result block is just what I needed. > > IMO, needing ':exports results' for inline src blocks is a bug not a > feature. > Agreed, particularly in light of Eric's comments at http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg00285.html There's the variable org-babel-inline-header-args, but it seems using #+PROPERTY: header-args :exports both overrules/breaks it Would org want something like #+PROPERTY: inline-header-args :exports results Or just 'hard-code' :exports results for all inline blocks?
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Or perhaps to survey what is already out there. What are people already doing/trying to do? On 21 March 2014 18:28, Bastien wrote: > Hi Nicolas, > > Nicolas Goaziou writes: > > > It would probably make my life less miserable. But do radio target users > > need entities within? > > IMHO the best way to know is to open a new thread with [POLL] > and a very clear subject like > > "[POLL] Do you need special entities in radio target?" > > 2 cents, > > -- > Bastien >
Re: [O] org-export-latex-hyperref-options-format
Nicolas Goaziou writes: >> If not, can someone offer advice on the best way to set >> org-latex-hyperref-template to achieve the same file-local effect? > > Assuming `org-export-allow-bind-keywords' is non-nil, does > > #+BIND: org-latex-hyperref-template "" > > work? I can't get this to work. Here is the top of my Org mode file: #+TITLE: Structure and Growth of the Leeward Kohala Field System: An Analysis with Directed Graphs #+DATE: #+LANGUAGE: en #+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t ':t ^:{} #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:nil pri:nil tags:not-in-toc #+BIND: org-latex-hyperref-template "" #+LATEX_CLASS: plos-devel #+STARTUP: entitiespretty #+PROPERTY: header-args:sh :eval no-export The variable org-export-allow-bind-keywords is t. When I open this file and ask for information about org-latex-hyperref-template, I get this: org-latex-hyperref-template is a variable defined in `ox-latex.el'. Its value is "\\hypersetup{\n pdfkeywords={%k},\n pdfsubject={%d},\n pdfcreator={%c}}\n" Org-mode version 8.2.5h (release_8.2.5h-757-gc444e4 @ /Users/dk/.emacs.d/src/org-mode/lisp/) All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] org-invoice for quotes/invoices
Hello, moving lot of stuff to Emacs/org-mode and would like to find some better way for generating quotes/invoices for our small/freelancer company. FOund out about org-invoice and wonder whether it's still alive and whether it can fully replace some php/mysql app I use atm for generating quotes/invoices along with PDF format? Anyone using it in combination with some other package to have complete invoicing solution (e.g. keepign records of all invoices, customers, bill's status like paid/due etc.)? Can you suggest some other (possibly) simple text-mode solution(s)? Sincerely, Gour -- One who sees inaction in action, and action in inaction, is intelligent among men, and he is in the transcendental position, although engaged in all sorts of activities. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
[O] org-export-format-source-code-or-example: End of Buffer
Dear org-mode list, I’m having a problem with org-mode source blocks in python when python-mode.el is enabled for python-mode instead of python.el. I detailed my problem here: http://stackoverflow.com/questions/22565379/emacs-org-mode-python-source-blocks-dont-export-with-python-mode-el and it looks like there is some history with a now non-existant function org-html-do-format-code here: http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg01018.html Appreciate any help. Cheers, Mish
Re: [O] Emacs freezes
[Christopher Witte (2014-03-21 15:29:24 UTC)] > Hi all, > > I'm getting a weird problem with orgmode and flyspell mode. Using the > latest version of org from git, open the attached file test.org and run M-x > flyspell-mode, emacs will lock up. It has something to do with tables. There is a thread "bug#17055: 24.3.50; Emacs hangs in Org mode file" on the list right now which seems to be about this same problem. I am not following that thread myself, so take this with a grain of salt. But have a look at it in the list archives for yourself. – Harald
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, Nicolas Goaziou writes: > It would probably make my life less miserable. But do radio target users > need entities within? IMHO the best way to know is to open a new thread with [POLL] and a very clear subject like "[POLL] Do you need special entities in radio target?" 2 cents, -- Bastien
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Bastien writes: > FWIW, I'd be fine to only allow plain text in radio targets, instead > of the full syntax. Your take. It would probably make my life less miserable. But do radio target users need entities within? Regards, -- Nicolas Goaziou
Re: [O] org-export-latex-hyperref-options-format
Hello, t...@tsdye.com (Thomas S. Dye) writes: > It would be great if the texht option could still be supported. The equivalent property is no longer a boolean. It can have complex values, which cannot be set on the OPTIONS line. > If not, can someone offer advice on the best way to set > org-latex-hyperref-template to achieve the same file-local effect? Assuming `org-export-allow-bind-keywords' is non-nil, does #+BIND: org-latex-hyperref-template "" work? Regards, -- Nicolas Goaziou
Re: [O] org-export-latex-hyperref-options-format
Thanks for the report. I'm not super familiar with how the texht option works. I did made the following change base on recommendation from Nicolas in the :options-alist. (:latex-hyperref-p nil "texht" org-latex-with-hyperref t) to (:latex-hyperref nil nil org-latex-hyperref-template t) >From Nicolas: "... we can replace "texht" with nil since it doesn't make much sense to specify a full template from the OPTIONS line." I believe the patch worked without substituting "texht" with nil in this line. I'm not sure if this is a regression or if your document requires updating. That's not my call. Just chiming in with what's relevant to this side effect you're experiencing. On Fri, Mar 21, 2014 at 11:51 AM, Thomas S. Dye wrote: > Aloha all, > > I noticed yesterday that a legacy document with this option: > > #+OPTIONS: texht:nil > > is now broken in a recent Org mode from master. > > The following lines now appear in the LaTeX export, when they didn't > before: > > \hypersetup{ > pdfkeywords={}, > pdfsubject={}, > pdfcreator={Emacs 24.3.1 (Org mode 8.2.5h)}} > > I haven't looked at this patch, but I'm guessing that it is responsible. > > It would be great if the texht option could still be supported. If not, > can someone offer advice on the best way to set > org-latex-hyperref-template to achieve the same file-local effect? > > All the best, > Tom > > > Bastien writes: > > > Hi Nicolas, > > > > Nicolas Goaziou writes: > > > >> I think this patch is already in master. > > > > Indeed, sorry for the noise, > > > > PS: let's confirm on the list when a patch gets applied, that > > helps archiving threads faster. > > -- > Thomas S. Dye > http://www.tsdye.com >
Re: [O] org-export-latex-hyperref-options-format
Aloha all, I noticed yesterday that a legacy document with this option: #+OPTIONS: texht:nil is now broken in a recent Org mode from master. The following lines now appear in the LaTeX export, when they didn't before: \hypersetup{ pdfkeywords={}, pdfsubject={}, pdfcreator={Emacs 24.3.1 (Org mode 8.2.5h)}} I haven't looked at this patch, but I'm guessing that it is responsible. It would be great if the texht option could still be supported. If not, can someone offer advice on the best way to set org-latex-hyperref-template to achieve the same file-local effect? All the best, Tom Bastien writes: > Hi Nicolas, > > Nicolas Goaziou writes: > >> I think this patch is already in master. > > Indeed, sorry for the noise, > > PS: let's confirm on the list when a patch gets applied, that > helps archiving threads faster. -- Thomas S. Dye http://www.tsdye.com
[O] I need help extending ob-ocaml to support :results output
Hello, It seems that ob-ocaml does not support ":results output". For instance, evaluating the following block: #+begin_src ocaml :results output Printf.printf "foo\nbar\n";; #+end_src Does not result in the two lines "foo" and "bar" but in the value being returned. Unfortunately I don't know enough of babel and emacs-lisp to extend ob-ocaml to support this. Would someone be willing to guide me through the `org-babel-execute:ocaml' function in ob-ocaml.el so that I can add this functionality? Thanks, Alan
[O] bug#17055: 24.3.50; Emacs hangs in Org mode file
> Still no prompt but Emacs survived this infloop (not an infloop, then) > after I don't know how much time (but more than a couple of minutes). Then try to M-x profiler-start RET RET <... reproduce ...> M-x profiler-report RET And the C-u RET on the + to expand the display. Stefan
[O] bug#17055: 24.3.50; Emacs hangs in Org mode file
> From: Sebastien Vauban > Date: Fri, 21 Mar 2014 14:58:19 +0100 > > Sebastien Vauban wrote: > > Today, 2 to 3 new infloops when editing in Org (but that's one of the > > two things I do: either be in Gnus, or in Org). > > > > Org-mode version 8.2.5h (release_8.2.5h-818-g0de200) > > > > I did not have time to look at the first ones; I do for this one. > > > > $ gdb -p 9696 > > ... > > [Thread 9696.0x1710 exited with code 0] > > [Thread 9696.0x23c4 exited with code 0] > > [Thread 9696.0x1e08 exited with code 0] > > > > The weird thing, here, is that my Bash terminal is stuck: I did not see > > more than 2 threads, and I don't have any GDB prompt yet. RET'ing does > > not change anything... > > > > Session still open (but no GDB prompt!). > > Still no prompt but Emacs survived this infloop (not an infloop, then) > after I don't know how much time (but more than a couple of minutes). > > BTW, it outputted the message "Emergency (alloc): Warning: past 95% of > memory limit". I think this is a duplicate of 16832. The same function, org-mode-flyspell-verify, causes this, and the effect is the same: it takes Emacs a lot of time to get out of that processing, whatever it is. I hope Org maintainers could take a good look on this.
[O] Emacs freezes
Hi all, I'm getting a weird problem with orgmode and flyspell mode. Using the latest version of org from git, open the attached file test.org and run M-x flyspell-mode, emacs will lock up. It has something to do with tables. Alternatively, make a new (empty) org file, run flyspell-mode, and start making a new table by writing |sdf|sdf|, and it will lock up emacs. Using an older version of org (7.9.3) this problem doesn't occur. I'm using Emacs 24.3.1 on Ubuntu 12.04. Any ideas what could be causing this? Thanks for your help. Chris. test.org Description: Binary data
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hi Nicolas, Nicolas Goaziou writes: > For example, `org-make-target-link-regexp' generates a regexp enclosed > within "\\<...\\>". Unfortunately, that will not match a radio link > starting with an entity, e.g., <<<\alpha-test>>> \alpha-test. It is > probably due to the fact that radio targets were initially meant to > contain only plain text, not Org syntax. FWIW, I'd be fine to only allow plain text in radio targets, instead of the full syntax. Your take. >> It's one of the last thing I want to get fixed before we release Org >> 8.2.3. > > If you don't mind, I need a bit more time (around a week) for 8.2.3. In > particular, there are speed issues in `org-element-context' that I would > like to fix first. Sure -- there is absolutely no rush, and I have my own share of things I need to fix too, so let's no hurry at all. I was mentioning 8.2.3 because Stefan created the emacs-24 branch, which means that the move toward Emacs 24.4 is accelerating now, but there is no deadline that I'm aware of. Thanks again, -- Bastien
Re: [O] #+HOMEPAGE in metadata - feature request?
I think already 'supported' in the sense that something like #+HOMEPAGE: would count as being an in-buffer setting as described in the http://orgmode.org/manual/In_002dbuffer-settings.html Org mode uses special lines in the buffer to define settings on a per-file basis. These lines start with a '#+' followed by a keyword, a colon, and then individual words defining a setting. On Fri, Mar 21, 2014 at 10:07 PM, Bastien wrote: > Hi Marcin, > > Marcin Borkowski writes: > > > what about adding #+HOMEPAGE (alongside #+AUTHOR and #+EMAIL) to the > > metadata? > > What would it do? > > > What are the pros and cons? (One argument against: default > > LaTeX classes do not support this. Any other?) > > Not sure what "supporting" means :) > > -- > Bastien > >
Re: [O] Radio targets with mixed capitalisation do not work in HTML export
Hello, Bastien writes: > Bastien writes: > >> Can you make the change (ie. radio-link is a link with a description, >> the description being its parsed path)? If so, do you want me to make >> the change in the backends or do you want to take care of this too? > > I see you reverted related commits -- are you on this? I reverted them because they introduced an infloop that I didn't have time to fix. I'm working on it, slowly. There are also a couple of problems related to radio targets that need to be fixed at the same time. For example, `org-make-target-link-regexp' generates a regexp enclosed within "\\<...\\>". Unfortunately, that will not match a radio link starting with an entity, e.g., <<<\alpha-test>>> \alpha-test. It is probably due to the fact that radio targets were initially meant to contain only plain text, not Org syntax. Anyway, I think it should be enclosed to something like "\\(?:\\W\\|^\\)..."\\(?:\\W\\|$\\)" instead. > It's one of the last thing I want to get fixed before we release Org > 8.2.3. If you don't mind, I need a bit more time (around a week) for 8.2.3. In particular, there are speed issues in `org-element-context' that I would like to fix first. Regards, -- Nicolas Goaziou
Re: [O] [BUG] `org-open-at-point' cannot open links to headlines with accented characters
Nicolas Goaziou writes: > Fixed, with tests. Thank you. Thanks a lot for the quick fix ! -- Bastien
Re: [O] [BUG] `org-open-at-point' cannot open links to headlines with accented characters
Hello, Bastien writes: > I cannot follow the link here: > > > * Définition > > [[*D%C3%A9finition][Définition]] > > > it asks me to create a headline. The link has been stored then > inserted with `org-store-link' and `org-insert-link'. > > The problem only happens with accented characters. Fixed, with tests. Thank you. Regards, -- Nicolas Goaziou
Re: [O] iCal-Export: Strange Results
Am 21.03.2014 13:25, schrieb Bastien: [...] The default value of `org-export-with-tasks' is `t', which will export all tasks. You can narrow to not-done tasks with: (setq org-export-with-tasks 'todo) Ah, thanks. I studied all the ical export settings, that's why I missed this generic setting for all exports. Probably this will do it. I'll check. Best Martin -- | G. Martin Butz, m...@mkblog.org, 0421 98749324, www.mkblog.org |
Re: [O] Context of interaction vs. literal syntactic interpretation
Hello, Bastien writes: > let's finally close this thread, thanks all for your inputs. I'm still waiting for Carsten's input, as I need to know whether introducing the parser in core functions is a goal for Org or not. Regards, -- Nicolas Goaziou
Re: [O] #+HOMEPAGE in metadata - feature request?
Hi Marcin, Marcin Borkowski writes: > what about adding #+HOMEPAGE (alongside #+AUTHOR and #+EMAIL) to the > metadata? What would it do? > What are the pros and cons? (One argument against: default > LaTeX classes do not support this. Any other?) Not sure what "supporting" means :) -- Bastien
Re: [O] org-export-latex-hyperref-options-format
Hi Nicolas, Nicolas Goaziou writes: > I think this patch is already in master. Indeed, sorry for the noise, PS: let's confirm on the list when a patch gets applied, that helps archiving threads faster. -- Bastien
Re: [O] org-export-latex-hyperref-options-format
Hello, Bastien writes: > can you repost the patch by creating another thread with [PATCH] > in the subject line, and using plain text instead of HTML format? > > If you don't use plain text email, simply attach the patch instead > of including it in the body of the email. > > Nicolas, I'll let you decide whether this can be applid (on top > of master). I think this patch is already in master. Regards -- Nicolas Goaziou
[O] Custom babel execute command with existing syntax highlighting
Hi all! I have such block: #+BEGIN_SRC my-python import sys sys.platform #+END_SRC I want it to be with syntax highlighting, so it will looks like (in a org-file) exactly as: #+BEGIN_SRC python import sys sys.platform #+END_SRC (of course the value of org-src-fontify-natively is t). but in the same time I would like that that block will be executed by means of custom org-babel-execute:my-python command. How can I achieve that? Andrey
[O] #+HOMEPAGE in metadata - feature request?
Hi all (and devs;)), what about adding #+HOMEPAGE (alongside #+AUTHOR and #+EMAIL) to the metadata? What are the pros and cons? (One argument against: default LaTeX classes do not support this. Any other?) Regards, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] iCal-Export: Strange Results
Hi Martin, thanks for the details, good to know part of the bug is gone. "G. Martin Butz" writes: > I checked with the file I tested in February with. I now do get active > TODO-entries. No idea what I changed meanwhile. But I also get entries > for the DONE-state, which I do not want. The default value of `org-export-with-tasks' is `t', which will export all tasks. You can narrow to not-done tasks with: (setq org-export-with-tasks 'todo) HTH, -- Bastien
Re: [O] iCal-Export: Strange Results
Hi Bastien, thanks for getting back to this. Meanwhile I can live with exporting the whole agenda to ics. Am 21.03.2014 09:03, schrieb Bastien: Hi, "G. Martin Butz" writes: While importing and viewing one of my org files, I do get strange results: + I only see dates from DONE-entries + There might be e.g. an entry in the ical file/Iceowl dated to 09:57, 2nd of December 2013 + The body of the calendar entry in ical file/Iceowl contains: • State "DONE" from "TODO" [2013-12-02 Mo 09:57] meaning the entry is dated to the date and time I set the entry to "DONE" + I do not see any active TODO-entries at all I checked with the file I tested in February with. I now do get active TODO-entries. No idea what I changed meanwhile. But I also get entries for the DONE-state, which I do not want. we would need a minimal example of the .org file you try to export to iCalendar in order to reproduce those problems. Probably some come from the export options you are using, independantly of the iCal export backend. This is my test file: 8<- #+STARTUP:nologdone * TODO A Scheduled Event SCHEDULED: <2014-03-03 Mo 16:00> :PROPERTIES: :ID: d092bad5-6559-405f-8afd-a9515b372323 :END: * TODO A Scheduled Event with Deadline DEADLINE: <2014-03-13 Do 10:00> SCHEDULED: <2014-03-16 So 15:00> :PROPERTIES: :ID: 53958c17-4a83-4150-8213-895a76bf4db1 :END: * DONE A Scheduled Event Already Done SCHEDULED: <2014-02-24 Mo> - State "DONE" from "TODO" [2014-02-27 Do 09:14] :PROPERTIES: :ID: 745d0dc5-0ebd-40cc-80fd-e06d1170fa44 :END: * DONE Another Scheduled Event Already Done SCHEDULED: <2014-02-07 Fr 15:00> - State "DONE" from "TODO" [2014-02-27 Do 09:21] :PROPERTIES: :ID: 45b90294-7807-4aa0-a5a4-93a285be8624 :END: 8<- I get the following ics-file with C-c C-e c f: 8<- BEGIN:VCALENDAR VERSION:2.0 X-WR-CALNAME:test PRODID:-//G. Martin Butz//Emacs with Org mode//EN X-WR-TIMEZONE:CET X-WR-CALDESC:test CALSCALE:GREGORIAN BEGIN:VEVENT DTSTAMP:20140321T120206Z UID:SC-d092bad5-6559-405f-8afd-a9515b372323 DTSTART:20140303T16 DTEND:20140303T18 SUMMARY:S: A Scheduled Event CATEGORIES:TODO END:VEVENT BEGIN:VTODO UID:TODO-d092bad5-6559-405f-8afd-a9515b372323 DTSTAMP:20140321T120206Z DTSTART:20140303T16 SUMMARY:A Scheduled Event CATEGORIES:TODO SEQUENCE:1 PRIORITY:5 STATUS:NEEDS-ACTION END:VTODO BEGIN:VEVENT DTSTAMP:20140321T120206Z UID:DL-53958c17-4a83-4150-8213-895a76bf4db1 DTSTART:20140313T10 DTEND:20140313T12 SUMMARY:DL: A Scheduled Event with Deadline CATEGORIES:TODO END:VEVENT BEGIN:VEVENT DTSTAMP:20140321T120206Z UID:SC-53958c17-4a83-4150-8213-895a76bf4db1 DTSTART:20140316T15 DTEND:20140316T17 SUMMARY:S: A Scheduled Event with Deadline CATEGORIES:TODO END:VEVENT BEGIN:VTODO UID:TODO-53958c17-4a83-4150-8213-895a76bf4db1 DTSTAMP:20140321T120206Z DTSTART:20140316T15 SUMMARY:A Scheduled Event with Deadline CATEGORIES:TODO SEQUENCE:1 PRIORITY:5 STATUS:NEEDS-ACTION END:VTODO BEGIN:VEVENT DTSTAMP:20140321T120206Z UID:SC-745d0dc5-0ebd-40cc-80fd-e06d1170fa44 DTSTART;VALUE=DATE:20140224 DTEND;VALUE=DATE:20140225 SUMMARY:S: A Scheduled Event Already Done CATEGORIES:DONE END:VEVENT BEGIN:VEVENT DTSTAMP:20140321T120206Z UID:TS1-745d0dc5-0ebd-40cc-80fd-e06d1170fa44 DTSTART:20140227T091400 DTEND:20140227T111400 SUMMARY:A Scheduled Event Already Done CATEGORIES:DONE END:VEVENT BEGIN:VEVENT DTSTAMP:20140321T120206Z UID:SC-45b90294-7807-4aa0-a5a4-93a285be8624 DTSTART:20140207T15 DTEND:20140207T17 SUMMARY:S: Another Scheduled Event Already Done CATEGORIES:DONE END:VEVENT BEGIN:VEVENT DTSTAMP:20140321T120206Z UID:TS1-45b90294-7807-4aa0-a5a4-93a285be8624 DTSTART:20140227T092100 DTEND:20140227T112100 SUMMARY:Another Scheduled Event Already Done CATEGORIES:DONE END:VEVENT END:VCALENDAR 8<- My settings at the time: 8<- (setq org-combined-agenda-icalendar-file "~/org/ical/org.ics") (setq org-icalendar-combined-agenda-file "~/org/ical/org.ics") (setq org-icalendar-categories (quote (todo-state))) (setq org-icalendar-combined-name "OrgIcal") (setq org-icalendar-include-body nil) (setq org-icalendar-include-todo t) (setq org-icalendar-use-deadline (quote (event-if-todo))) (setq org-icalendar-store-UID t) (setq org-icalendar-use-plain-timestamp nil) (setq org-icalendar-use-scheduled nil) (setq org-icalendar-with-timestamps nil) (setq org-icalendar-use-scheduled '(todo-start event-if-todo)) 8<- Or maybe this got sorted out in the meantime, who knows. See above: In a way yes. Thanks for further information, Thank you Martin -- | G. Martin Butz, m...@
Re: [O] [ANN] orgbox: Mailbox-like task scheduling in org-agenda.
Hello Alan, > It would be great to be able to configure some of the hard-coded dates > and time, such as: > - later today: number of hours (currently 3) > - start of evening: currently 18:00 > - start of day: currently 08:00 > - start of weekend: currently Saturday (you could use > `org-agenda-weekend-days' as you are doing for the `orgbox-weekend-p' > predicate) > - start of week: currently Monday, at 08:00 > - someday: currently in 3 months Yes, I would add these defcustoms in the next comming release. Thanks for your valuable comments! Yasuhito On Fri, Mar 21, 2014 at 4:28 PM, Alan Schmitt wrote: > Hello Yasuhito, > > Yasuhito Takamiya writes: > >> Hello all, >> >> For your information, to anyone interested in GTD and org-mode, >> I am developing a tiny tool for org-mode to schedule your agenda tasks >> easily like Mailbox iPhone app (http://www.mailboxapp.com/). >> >> https://github.com/yasuhito/orgbox >> (This is already available on MELPA.) >> >> Usage: >> - Open org-agenda view. >> - Move your cursor to a task you want to schedule and type C-c C-s >> (or M-x orgbox). >> - Select one of the scheduling method from the menu shown on the >> minibuffer. >> >> - [l] Later Today >> - [e] This Evening >> - [t] Tomorrow >> - [w] This Weekend >> - [n] Next Week >> - [i] In a Month >> - [s] Someday >> - [p] Pick Date >> >> If anyone is interested in being involved in taking this forward, >> that'd be great. > > I had a quick look at your code and this looks like a nice idea. I have > a couple comments. > > It would be great to be able to configure some of the hard-coded dates > and time, such as: > - later today: number of hours (currently 3) > - start of evening: currently 18:00 > - start of day: currently 08:00 > - start of weekend: currently Saturday (you could use > `org-agenda-weekend-days' as you are doing for the `orgbox-weekend-p' > predicate) > - start of week: currently Monday, at 08:00 > - someday: currently in 3 months > > I don't know how difficult it would be to make these user configurable. > In any case, I find this is a very useful addition to scheduling in org > mode. > > Thanks, > > Alan
[O] [BUG] `org-open-at-point' cannot open links to headlines with accented characters
Hi Nicolas, I cannot follow the link here: * Définition [[*D%C3%A9finition][Définition]] it asks me to create a headline. The link has been stored then inserted with `org-store-link' and `org-insert-link'. The problem only happens with accented characters. Do you see what can be wrong here? Thanks, -- Bastien
Re: [O] [ANN] orgbox: Mailbox-like task scheduling in org-agenda.
Hi, > From a mnemonic point of view, I would rather choose [m] for "in a > month". Ah I totally agree && fixed in the latest release. Thank you very much for your comments. Yasuhito On Fri, Mar 21, 2014 at 7:03 PM, Karl Voit wrote: > * Yasuhito Takamiya wrote: >> Hello all, > > Hi! > > Short remark: > >> - [l] Later Today >> - [e] This Evening >> - [t] Tomorrow >> - [w] This Weekend >> - [n] Next Week >> - [i] In a Month > > From a mnemonic point of view, I would rather choose [m] for "in a > month". > > -- > mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: >> get Memacs from https://github.com/novoid/Memacs < > > https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github > >
Re: [O] Effort property inheritance?
Hi Sébastien, fixed, thanks, -- Bastien
Re: [O] Generate and display image
i find you have to toggle the inline images (org-toggle-inline-images) two times to do that. once to turn the old images off, and once to turn them all back on. C-c C-x C-v runs that command for me. 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 Fri, Mar 21, 2014 at 7:36 AM, Andrey Tykhonov wrote: > > Hi all! > > What I want to do is to generate image (better to say a path to an image) > in the org-file and then see it posted in my blog. > > For example, I have such block: > > #+BEGIN_SRC text2image :exports results > Foo > Bar > Baz > #+END_SRC > > There is text2image command line utility which takes a text and converts it > to the image, then returns a path to the image. > > When I execute that block by means of `org-babel-execute-src-block' that > block executes correctly and returns a path: > > #+RESULTS: > : [[/home/demi/images/2014-03-21-024756.png]] > > The issue is that that after execution of > `org2blog/wp-post-buffer-and-publish' I'm expecting to see in the blog post > the image but I see this path literally (instead of image): > > [[/home/demi/images/2014-03-21-024756.png]] > > > How to fix that issue? Please help. > > I tried to change text2image program to return a path with a prefix "file:" > and "file:///" but that didn't help. > > > > Andrey > >
[O] Generate and display image
Hi all! What I want to do is to generate image (better to say a path to an image) in the org-file and then see it posted in my blog. For example, I have such block: #+BEGIN_SRC text2image :exports results Foo Bar Baz #+END_SRC There is text2image command line utility which takes a text and converts it to the image, then returns a path to the image. When I execute that block by means of `org-babel-execute-src-block' that block executes correctly and returns a path: #+RESULTS: : [[/home/demi/images/2014-03-21-024756.png]] The issue is that that after execution of `org2blog/wp-post-buffer-and-publish' I'm expecting to see in the blog post the image but I see this path literally (instead of image): [[/home/demi/images/2014-03-21-024756.png]] How to fix that issue? Please help. I tried to change text2image program to return a path with a prefix "file:" and "file:///" but that didn't help. Andrey
Re: [O] verbatim/code text and line breaks with auto fill mode
Resending this as it did not make it to the list. (Is there a way to make sure that mail that makes it to the list through gmail gets a reply address to the list?) Alan Schmitt writes: > Bastien writes: > >>> If it does, what backends do not support it? >> >> Only the LaTeX backend. >> >> I fixed this by replacing newlines characters with whitespace >> characters in \verb constructs for the LaTeX backend. > > This seems like a good solution to me. Thanks! > > Alan
[O] Effort property inheritance?
Hello, When using this minimal configuration: --8<---cut here---start->8--- (setq org-agenda-prefix-format '((agenda . " %-11s%i %-12:c%?-12t%7e ") (timeline . " % s") (todo . " %i %-12:c") (search . " %i %-12:c") (tags . " %i %-12:c"))) (setq org-agenda-files '("~/agenda.org")) --8<---cut here---end--->8--- where ~/agenda.org is: --8<---cut here---start->8--- * Projects ** Projet A :PROPERTIES: :Effort: 104:00 :END: *** TODO Do this... DEADLINE: <2014-03-20 Thu> *** TODO Do that as well! DEADLINE: <2014-03-21 Fri> --8<---cut here---end--->8--- I did _not_ expect to see the effort of the whole project "applied" on every of its subtasks: --8<---cut here---start->8--- Week-agenda (W12): Monday 17 March 2014 W12 Tuesday18 March 2014 Wednesday 19 March 2014 Thursday 20 March 2014 Deadline: agenda: [104:00] TODO Do this... Friday 21 March 2014 1 d. ago: agenda: [104:00] TODO Do this... Deadline: agenda: [104:00] TODO Do that as well! Saturday 22 March 2014 Sunday 23 March 2014 --8<---cut here---end--->8--- Just to confirm once more (than what's in the ECM), here is the value of `org-use-property-inheritance': ╭ │ org-use-property-inheritance is a variable defined in `org.el'. │ Its value is nil │ │ Documentation: │ Non-nil means properties apply also for sublevels. │ │ This setting is chiefly used during property searches. Turning it on can │ cause significant overhead when doing a search, which is why it is not │ on by default. │ │ When nil, only the properties directly given in the current entry count. │ When t, every property is inherited. The value may also be a list of │ properties that should have inheritance, or a regular expression matching │ properties that should be inherited. │ │ However, note that some special properties use inheritance under special │ circumstances (not in searches). Examples are CATEGORY, ARCHIVE, COLUMNS, │ and the properties ending in "_ALL" when they are used as descriptor │ for valid values of a property. ╰ Am I missing something? Best regards, Seb -- Sebastien Vauban
Re: [O] agenda: is it possible to avoid displaying empty sections
Hi, Bastien writes: > Hi Alan and Ken, > > Ken Mankoff writes: > >> I think the answer is "no" based on the replies to me asking this >> exact same question last June: >> https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00681.html Sorry, I did not remember this conversation. Thank you for the link. > Yes, it is not possible, but highly desirable. > > On top of my TODO list. Ah, this is good to know! Thanks again, Alan
Re: [O] [ANN] orgbox: Mailbox-like task scheduling in org-agenda.
* Yasuhito Takamiya wrote: > Hello all, Hi! Short remark: > - [l] Later Today > - [e] This Evening > - [t] Tomorrow > - [w] This Weekend > - [n] Next Week > - [i] In a Month >From a mnemonic point of view, I would rather choose [m] for "in a month". -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] agenda: is it possible to avoid displaying empty sections
Hi Alan and Ken, Ken Mankoff writes: > I think the answer is "no" based on the replies to me asking this > exact same question last June: > https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00681.html Yes, it is not possible, but highly desirable. On top of my TODO list. -- Bastien
Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Hi Nicolas, Nicolas Goaziou writes: > What about excluding most tempting locations instead? I pushed a change, mixing this suggestion and the suggestion to be more explicit about where it is allowed: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=343a6dd0 Luke, let's us know if it is clearer. -- Bastien
Re: [O] agenda: is it possible to avoid displaying empty sections
Hi Alan, On 2014-03-21 at 04:29, Alan Schmitt wrote: > Hello, > > I have several sections in my "review" agenda that I try to make empty > ("Tasks to refile", "Tag me", "Stuck Projects", ...). Is it possible to > avoid displaying the section title when it does not have any contents? > I think the answer is "no" based on the replies to me asking this exact same question last June: https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00681.html But a recent thread earlier this month on how to re-use Agenda sections made me think, "maybe it is possible". I haven't explored this latter idea further: https://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg00459.html -k.
Re: [O] verbatim/code text and line breaks with auto fill mode
Hi Nicolas and Alan, Nicolas Goaziou writes: > We first need to know what is the problem. Does Org allow newline > characters in verbatim objects? I'd say it should, yes. Otherwise it creates an exception that is hard to justify, since this exception is linked to only one export backend. > If it does, what backends do not support it? Only the LaTeX backend. I fixed this by replacing newlines characters with whitespace characters in \verb constructs for the LaTeX backend. -- Bastien
Re: [O] Context of interaction vs. literal syntactic interpretation
Hi all, let's finally close this thread, thanks all for your inputs. The solution I suggest is this: 1. implement multi-links opening when C-c C-o is called in a paragraph and there is no link at point (similar behavior than the one we have for links in headlines); 2. let `org-open-at-point' fall back on ffap so that raw links in comments and anywhere else can be open. (If needed, this behavior could be bound to an option.) 3. factor out `org-open-in-paragraph' and `org-open-in-headline' from `org-open-at-point' so that `org-open-at-point' does what its names says it should do. I will implement this in master. Thanks, -- Bastien
Re: [O] LaTeX export: Handle hash symbol in footnote url links
Hi Nicolas, Nicolas Goaziou writes: > 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? AFAIK in footnotes only, for the # ^ ! & characters (% is already escaped.) But I'm not sure we should fix this at Org's level: there is the bigfoot package* that is fixes it, it seems a common LaTeX problem and solution: * http://www.ctan.org/tex-archive/macros/latex/contrib/bigfoot/ -- Bastien
[O] agenda: is it possible to avoid displaying empty sections
Hello, I have several sections in my "review" agenda that I try to make empty ("Tasks to refile", "Tag me", "Stuck Projects", ...). Is it possible to avoid displaying the section title when it does not have any contents? Thanks, Alan
Re: [O] (setq org-icalendar-store-UID t) not working with --batch
Hi, Boyd Kelly writes: > But when I run: emacs -l ~/.emacs -eval ' > (org-export-icalendar-all-agenda-files)' --batch ^ This function does not exist in the current distribution of Org, and the problem does not exist in this distribution AFAIK. If you can, please update Org. Thanks, -- Bastien
Re: [O] [PATCH] Source block fontification handling indentation
Hi Michael, thanks for the patch. Pontus Michael writes: > Primary reason for this change is to fix the problem which I describe > as > follows: > > This function is not 100% compatible with a org-edit-src facility, > which provides an option to have indentation added to the code inside > the block after using command `org-edit-src-code' to edit it. This > command also handles removal of indentation upon insertion of the > code > in temporary buffer where editing of the code will in relevant > major-mode. I'm not sure I understand what the real problem is. Can you describe it against the behavior of the current version? And maybe provide a minimal recipe to reproduce it? Did you catch any side-effect of your patch? Thanks, -- Bastien
[O] bug#16751: 24.3.50; Export during Org export to HTML
Hi Eli, Eli Zaretskii writes: > I fixed expand-file-name (trunk revision 116624). Thanks. > I'm keeping the bug open until the Org part is either fixed or we > decide it doesn't need fixing. In my opinion, it needs a fix, but it's quite a rewrite, so don't expect any change here before Org 9.0. If someone wants to work on this, help is welcome. Let's keep the bug open in the meantime. -- Bastien
Re: [O] Out of Order Evaluation
Andreas Leha writes: > Charles Berry writes: > >> Andreas Leha med.uni-goettingen.de> writes: >> >>> >>> Hi Michael, >>> >>> Michael Weylandt gmail.com> writes: >>> >>> > Hi, >>> > >>> > I want to put a summary of my analysis at the beginning of a document >>> > using results calculated at the end of the document. Is this possible? >> >> [snip] >> >>> > >>> > Is this possible in a single pass? >> >> >> Not quite. The method suggested by Andreas computes the result twice. If >> there is any randomness in the results (as in the example) you will get a >> different answer in the summary than when the block is later evaluated. >> > > Well, you could enter the ':cache yes' world here. Although, for me, > that produced more problems than it solved (since there is no tracking > of dependencies among code blocks in :session mode). > > My typical workflow now is something 'less literate': My typical > project Org file will look like this: > > * Execution > This is full of #+call: lines. By (my own) convention, this subtree has > to be evaluated before exporting the next subsection. > > * Report > This is the report / presentation. > > * Analysis > This contains all the code block to be called from the Execution > subtree. > (Plus usually quite a lot of code blocks from dead ends of the > project...) > > > This solves your problem (and is along the lines Charles suggests as > well), but requires more work than just export the document and is, > thus, less literate. I should add here, that working with #+call lines is not too convenient. These are missing some functionality compared to source blocks. Most importantly 'C-c C-v v' and 'C-c C-v n' are missing. I wanted to have a look at those for quite some time, but have not gotten around to do so. Regards, Andreas > > Regards, > Andreas > > > >>> > I've played with #+NAME and >>> > <> but haven't gotten the out-of-order evaluation quite >>> > right. >> >> You can use >> >> #+results: the-mean >> >> before >> >> #+NAME: the-mean >> #+begin_src R >> mean(x) >> #+end_src >> >> which is after 'theanalysis' block. >> >> And if the format is not pleasing add a filter that reformats the result. >> >> >>> > >>> > Michael >>> > >>> >>> How about something along: >>> >>> --8<---cut here---start->8--- >>> #+TITLE: Test >>> #+AUTHOR: Michael Weylandt >>> #+PROPERTY: header-args:R :session *__R__* :exports both >>> >>> * Summary >>> The mean result was src_R[:exports results :var >> analysisresults=theanalysis()]{mean(unlist(analysisresults))} >>> >>> * Analysis, >>> We do some complicated calculations: >>> >>> #+name: theanalysis >>> #+BEGIN_SRC R >>> x <- rnorm(5) >>> #+END_SRC >>> --8<---cut here---end--->8--- >> >> >> It might be better to mark all the blocks in the doc ':eval never' >> and ':exports code' or ':exports none' and put blocks before the first >> headline that do all the calcs from noweb references, and put the #+results >> lines (if you need them) wherever you want them in the doc. Like so: >> >> >> >> #+TITLE: Test >> #+AUTHOR: Michael Weylandt >> #+PROPERTY: header-args:R :session *__R__* :exports both >> >> >> #+NAME: master >> #+BEGIN_SRC R :noweb yes :results silent :exports results >> <> >> #+END_SRC >> >> * Summary >> >> >> The mean result was src_R[:exports results]{mean(x)} >> >> * Analysis, >> We do some complicated calculations: >> >> #+name: theanalysis >> #+BEGIN_SRC R :eval never :exports code >> x <- rnorm(5) >> #+END_SRC >> >> >> IMO, needing ':exports results' for inline src blocks is a bug not a >> feature. >> >> HTH, >> >> Chuck
Re: [O] custom link export and ox-md
Hi Nick and Nicolas, can we move forward on this patch? It is good, modulo Nicolas suggestions, which seems good to me. > This raises an interesting question. What do we do with derived > back-ends? E.g., what should happen if TYPE is handled in > `org-link-protocols' for `html' but not `md'? I'm not sure I understand the problem, but I guess it can be fixed separately from the issue addressed by the patch. Anyway, yes, this would go to master, as a small enhancement. Thanks, -- Bastien
Re: [O] Org release 8.2.5g (minor release from maint)
Hi Richard, thanks for your detailed account on The Debian Way. Richard Lawrence writes: > If introducing a dependency on cl-lib right now > will be the best thing for Org, I have no real objections; if it can be > put off for a while without significant cost, that would be great, but > it isn't necessary. I suggest we make this happen for Org 9.0. The big version number will be scary enough to make people carefully check backward compatibility issues. We could even stick to this policy: no backward compatibility issue between minor (i.e. X.X) versions. I think it's close to what we've been doing so far. In the meantime, I suggest we add a comment on top of compatibility functions that we might remove in Org 9.0. Eric, could you do that based on the list you provided? Thanks to both, -- Bastien
Re: [O] iCal-Export: Strange Results
Hi, "G. Martin Butz" writes: > While importing and viewing one of my org files, I do get strange results: > > + I only see dates from DONE-entries > + There might be e.g. an entry in the ical file/Iceowl dated to > 09:57, 2nd of December 2013 > + The body of the calendar entry in ical file/Iceowl contains: > • State "DONE" from "TODO" [2013-12-02 Mo 09:57] meaning > the entry is dated to the date and time I set the entry to "DONE" > + I do not see any active TODO-entries at all we would need a minimal example of the .org file you try to export to iCalendar in order to reproduce those problems. Probably some come from the export options you are using, independantly of the iCal export backend. Or maybe this got sorted out in the meantime, who knows. Thanks for further information, -- Bastien
Re: [O] Out of Order Evaluation
Charles Berry writes: > Andreas Leha med.uni-goettingen.de> writes: > >> >> Hi Michael, >> >> Michael Weylandt gmail.com> writes: >> >> > Hi, >> > >> > I want to put a summary of my analysis at the beginning of a document >> > using results calculated at the end of the document. Is this possible? > > [snip] > >> > >> > Is this possible in a single pass? > > > Not quite. The method suggested by Andreas computes the result twice. If > there is any randomness in the results (as in the example) you will get a > different answer in the summary than when the block is later evaluated. > Well, you could enter the ':cache yes' world here. Although, for me, that produced more problems than it solved (since there is no tracking of dependencies among code blocks in :session mode). My typical workflow now is something 'less literate': My typical project Org file will look like this: --8<---cut here---start->8--- * Execution This is full of #+call: lines. By (my own) convention, this subtree has to be evaluated before exporting the next subsection. * Report This is the report / presentation. * Analysis This contains all the code block to be called from the Execution subtree. (Plus usually quite a lot of code blocks from dead ends of the project...) --8<---cut here---end--->8--- This solves your problem (and is along the lines Charles suggests as well), but requires more work than just export the document and is, thus, less literate. Regards, Andreas >> > I've played with #+NAME and >> > <> but haven't gotten the out-of-order evaluation quite >> > right. > > You can use > > #+results: the-mean > > before > > #+NAME: the-mean > #+begin_src R > mean(x) > #+end_src > > which is after 'theanalysis' block. > > And if the format is not pleasing add a filter that reformats the result. > > >> > >> > Michael >> > >> >> How about something along: >> >> --8<---cut here---start->8--- >> #+TITLE: Test >> #+AUTHOR: Michael Weylandt >> #+PROPERTY: header-args:R :session *__R__* :exports both >> >> * Summary >> The mean result was src_R[:exports results :var > analysisresults=theanalysis()]{mean(unlist(analysisresults))} >> >> * Analysis, >> We do some complicated calculations: >> >> #+name: theanalysis >> #+BEGIN_SRC R >> x <- rnorm(5) >> #+END_SRC >> --8<---cut here---end--->8--- > > > It might be better to mark all the blocks in the doc ':eval never' > and ':exports code' or ':exports none' and put blocks before the first > headline that do all the calcs from noweb references, and put the #+results > lines (if you need them) wherever you want them in the doc. Like so: > > > > #+TITLE: Test > #+AUTHOR: Michael Weylandt > #+PROPERTY: header-args:R :session *__R__* :exports both > > > #+NAME: master > #+BEGIN_SRC R :noweb yes :results silent :exports results > <> > #+END_SRC > > * Summary > > > The mean result was src_R[:exports results]{mean(x)} > > * Analysis, > We do some complicated calculations: > > #+name: theanalysis > #+BEGIN_SRC R :eval never :exports code > x <- rnorm(5) > #+END_SRC > > > IMO, needing ':exports results' for inline src blocks is a bug not a > feature. > > HTH, > > Chuck
Re: [O] orgtble and flyspell interaction causing mem exhaustion error?
Hi Charles, Charles Millar writes: > I guess it's fixed. Thanks for confirming, -- Bastien
Re: [O] org-export-latex-hyperref-options-format
Hi Joe, Joe Hirn writes: > Against the latest master: can you repost the patch by creating another thread with [PATCH] in the subject line, and using plain text instead of HTML format? If you don't use plain text email, simply attach the patch instead of including it in the body of the email. Nicolas, I'll let you decide whether this can be applid (on top of master). Thanks, -- Bastien
Re: [O] Behavior of Org mode Babel code snippets with respect to M-q (fill-paragraph) and C-/ (undo)
Hi Samuel, Samuel Wales writes: > "[bug] [babel] babel corrupts undo history" I've reread this thread but I currently nothing wrong with undoing wrt source code editing. Let me know if I missed something, thanks, -- Bastien
Re: [O] Verify Org-mode syntax
* Nicolas Goaziou wrote: > Hello, Hi Nicolas! > Karl Voit writes: > >> Currently, I do have some issues like [1] which sometimes cause "loss >> of data" [2] and multiple times a day(!) my Emacs enters some endless >> loop so that I have to kill it [3]. Very annoying and frustrating. >> >> Therefore, I've got the feeling that at least some issues are >> related to messed up Org-mode syntax like [1]. >> >> How can I verify Org-mode syntax to identify at least some obvious >> issues? >> >> 1. http://article.gmane.org/gmane.emacs.orgmode/83167 >> >> 2. This is somewhat exaggerated. When a time-stamp on the wrong >> position messes up a SCHEDULED line, the issue never gets listed >> on my agenda and is therefore "lost" to me. >> >> 3. Both, on Windows and Linux! > > [1] should be fixed. Does it still happen with a recent Org? Yippie! :-) Yes, it is fixed now. > [3] should be fixed too. Please update Org. Did I understand you correctly? There was an issue with an endless CPU-consuming loop which should be gone now? If yes, I have to check the next days since this annoying issue is not reproducible with a certain operation. It happens from time to time on misc operations such as adding a "|" in front of a line, re-scheduling a task on the agenda, swapping table lines, and so on. > I don't understand [2], though. Could you show an example? With [1] I had the issue with lines like: :LAST_REPEAT: [2014-03-16 Sun 16:19]:LOGBOOK: which messed up the LOGBOOK drawer at least. I do not have a clue, which Org-mode elements were messed up as well. Therefore, I asked for a quick/rough syntax checking method for my files. -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: > get Memacs from https://github.com/novoid/Memacs < https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] [BUG] `org-agenda-sorting-strategy' does not work in `tags-todo'
Hi Sébastien, "Sebastien Vauban" writes: > Though the "deadline-up" sorting does not work, as demo'ed in the > previous post. Can you point at that post again? Also, the example in your previous email is quite complex. If something does not work in `org-agenda-sorting-strategy' can you make the example minimal, with no special config or skip functions? I'd like to fix any problem in this area before 8.2.3, which will go into Emacs 24.4. Thanks in advance, -- Bastien
[O] bug#16734: Default value org-odt-data-dir (in Emacs) makes no sense
Hi Glenn, Glenn Morris writes: > Package: emacs,org-mode > Version: 24.3.50 > > This refers to the version of Org mode in Emacs trunk. > > ./src/emacs -Q -l ox-odt > C-h v org-odt-data-dir > -> Its value is "/usr/share/emacs/etc/org" > > This value is hard-coded (and autoloaded; why?) in org-version.el. > This value makes no sense. > For Emacs, it should be something based on data-directory. Yes. > This was pointed out before in some moderately lengthy discussion: > > http://lists.gnu.org/archive/html/emacs-devel/2012-10/msg2.html > http://lists.gnu.org/archive/html/emacs-devel/2012-10/msg00070.html For now we will keep `org-odt-data-dir' in org-version.el that comes with Org separate distributions (git, tar.gz and zip archives.) > (In general, the setting of directory-related variables in ox-odt seems > rather over-engineered.) Indeed, we need to revisit this. -- Bastien
[O] ATTN: Users of ODT exporter
ATTN: Users of ODT exporter If you want to talk to me wrt exporter, please add a note here: http://www.emacswiki.org/emacs/Jambunathan_K I am leaving this list. I WILL NEVER MAKE an assignment to Emacs. i.e. The development that happens on my repository will NEVER hit the Emacs trunk.