Re: [O] Setting a parametric org-agenda-skip-function?
strom...@nexgo.de writes: Alan Schmitt writes: It would be great except for the following: as soon as I use the debugger, my function works as intended. Is there any reason why using the debugger would change the behavior of a function? Sorry to be of no actual help, but if it's any consolation to you, this is common enough to have its own name: what you have there is called a Heisenbug. Thanks Achim and Anthony. If I ever make progress on this, I'll let you know. Alan
Re: [O] Right-to-left text in org mode
A work around seems to be to provide an empty line between the LTR and the RTL paragraph. I.e. instead of * this is ltr * THIS IS RTL do: * this is ltr * THIS IS RTL But you are correct that the wrapping of LTR paragraphs with RTL text is buggy. This bug seems to have nothing to do with org mode, but happens e.g. in text mode and fundamental mode as well. You should raise this issue on the emacs-list or file a bug with emacs. On Tue, Jun 25, 2013 at 7:27 AM, Manuel GJT valh...@gmail.com wrote: Specifically what additional information should I provide? This happens to me even without my .emacs loaded. I'm running Ubuntu 12.04 with m17n-(db/contrib), libm17n-(0/dev) installed. It seems that in org mode is forcing LTR in mixed-directionality texts since, for example, a heading with RTL text will not change the stars to be right-aligned, and the cursor's behavior in org mode is different than in a clean buffer. Perhaps you could show me how to ignore any previous paragraph settings other than with R-T-L MARK? Kind regards, Manuel GJT On Mon, Jun 24, 2013 at 12:49 PM, Dov Grobgeld dov.grobg...@gmail.com wrote: I was able to reproduce this behavior only with by forcing the paragraph direction to LTR or equivilantly by having a first strong LTR character in the beginning of the paragraph. Please provide more information about your environment, and someone might be able to help you. Regards, Dov On Mon, Jun 24, 2013 at 8:22 PM, Manuel GJT valh...@gmail.com wrote: Hello everyone, I need to work in an org buffer with both left-to-right and right-to-left text. Although the character directionality and composition works fine, when writing paragraphs with visual-line-mode on the lines get inverted, i.e., the line ZYX CBA appears as ZYX CBA instead of CBA ZYX The section 22.20 Bidirectional Editing of the Emacs manual suggests forcing the directionality of the paragraph with RIGHT-TO-LEFT MARK, but this does not seem to work: even with such a character beginning the line, (current-bidi-paragraph-direction) returns left-to-right. The RTL MARK seems to work just fine in tables. When written in a clean text-mode buffer the same text appears with proper directionality. However switching from org-mode to text-mode does not correct directionality in said paragraphs. The issue persists even when visiting the file with emacs -Q. org-version 8.0.3, same issue with v. 7.9.4 Your help is much appreciated. -- Manuel GJT -- Manuel GJT
Re: [O] [RFC]: Uniform indentation for lists
Hello Jambunathan, On Tue, Jun 25, 2013 at 03:28:34AM +0530, Jambunathan K wrote: I was wondering whether there would be some interest in 1) To eliminate the separators - . or ) - in the numbered list 2) Enhance the list repair routine so that it will alway indent by 3 spaces. With (1) above, the earlier list becomes, 1 One 2 Two - Bullet One - Bullet Two 1 One 2 Two I think it will still break for long lists (greater than 9 items). 9 item 10 item That said, if this is followed up, I would prefer (2). The . and ) tend to serve as useful indicators for me. I also find them helpful when I use the @ syntax. 3. [@3] Item 4. Another item Cheers, -- Suvayu Open source is the future. It sets us free.
[O] minor mode recentf: show only *.tex and *.org files?!
Hi! I'm using the minor mode recentf to get a list of recently opened files. But the list is cluttered with files like *.out, *.log and whatever. Can somebody drop me two or three lines, which I can put into my .emacs file to make recentf only show *.org and *.tex files? Thank you, Regards, Alexander
[O] Bug: (bisected) org-meta-return makes an error at end of a buffer [8.0.3 (release_8.0.3-239-g269c5f @ /home/youngfrog/sources/org-mode/lisp/)]
Hello, Evalling (progn (switch-to-buffer org-test.org) (org-mode) (insert * good day\n) ; no \n implies no error. (setq debug-on-error t) (org-meta-return)) makes an error git bisect says: , | 3c933adaf627bc8a58cfefb62ff0f2d5df640673 is the first bad commit ` That commit simply introduced (org-element-at-point) into (org-at-property-p), so I also ran a git bisect session with (org-element-at-point) instead of (org-meta-return) in the above because I guess org-element-at-point shouldn't actually make an error. Here is the result: , | 94bcc7e2828a42d5448757ab28cadbf663c9ff6d is the first bad commit | commit 94bcc7e2828a42d5448757ab28cadbf663c9ff6d | Author: Nicolas Goaziou n.goaz...@gmail.com | Date: Mon Feb 11 14:42:16 2013 +0100 | | org-element: Fix parsing of orphaned keyword at the end of an element | | * lisp/org-element.el (org-element--current-element): Add a limit | argument. | (org-element--collect-affiliated-keywords): Fix parsing of orphaned | keyword at the end of an element. | * testing/lisp/test-org-element.el: Add test. | | :04 04 180072bc91d21e7c3c893792e9a162268068477e e0e8d22d8a06f0601a585010be45d40dbb91b866 Mlisp | :04 04 ce3fa869b4f17ed3b3edce74f38cfdce8e70d4f4 58c55594d5f851eb8a8a19eaf12b3a6bd6884cfe Mtesting | bisect run success ` I don't know what the solution is because I don't understand the link between affiliated keywords and the fact that (= (point) limit) (this is the clause which is entered in the cond in org-element--current-element) -- Nico.
Re: [O] minor mode recentf: show only *.tex and *.org files?!
AW alexander.will...@t-online.de writes: I'm using the minor mode recentf to get a list of recently opened files. But the list is cluttered with files like *.out, *.log and whatever. Variable recentf-exclude is the answer. I have this : (setq recentf-exclude '( /.emacs.bmk$ \\.ido.last$ ; ido mode (emacs) session\\.[a-f0-9]*$ ; emacs ~$ ; emacs (and others) backup \\.log$ ; LaTeX \\.pdfsync$ ; LaTeX \\.toc ; LaTeX \\.aux$ ; LaTeX /Dropbox/ ; avoid opening dropbox files, there is probably a local mirror bssm2011-dropbox ; symbolic link to dropbox /COMMIT_EDITMSG$ /tmp/ .el.gz$ )) but obviously you want to adjust that to your situation. If you really only want org and tex files, you should ignore anything that doesn't end in org or tex, i.e. (setq recentf-exclude '( ; if filename... [^gx]$ ; doesn't end in gx [^e]x$ ; or ends in x but not ex [^r]g$ ; or ends in g but not rg [^t]ex$; or ends in ex but not tex [^o]rg$ ; or ends in rg but not org )) ; ...then exclude N.
Re: [O] minor mode recentf: show only *.tex and *.org files?!
Am Dienstag, 25. Juni 2013, 12:34:12 schrieb Nicolas Nicolas Richard:
AW alexander.will...@t-online.de writes:
I'm using the minor mode recentf to get a list of recently opened files.
But the list is cluttered with files like *.out, *.log and whatever.
Variable recentf-exclude is the answer.
I have this :
(setq recentf-exclude '(
/.emacs.bmk$
\\.ido.last$ ; ido mode (emacs)
session\\.[a-f0-9]*$ ; emacs
~$ ; emacs (and others) backup
\\.log$ ; LaTeX
\\.pdfsync$ ; LaTeX
\\.toc ; LaTeX
\\.aux$ ; LaTeX
/Dropbox/ ; avoid opening dropbox files, there is
probably a local mirror bssm2011-dropbox ; symbolic link to dropbox
/COMMIT_EDITMSG$
/tmp/
.el.gz$
))
but obviously you want to adjust that to your situation. If you really
only want org and tex files, you should ignore anything that doesn't end
in org or tex, i.e.
(setq recentf-exclude '( ; if filename...
[^gx]$ ; doesn't end in gx
[^e]x$ ; or ends in x but not ex
[^r]g$ ; or ends in g but not rg
[^t]ex$; or ends in ex but not tex
[^o]rg$ ; or ends in rg but not org
)) ; ...then exclude
N.
Thank you very much. Your way to exclude only some disturbing files seems much
better to me.
But I fail to exclude in Emacs 24.3 under Windows 7 lines in recentf like
this:
c:/Users/aw/AppData/Local/Temp/diary1234ABc
The filename is always diary + 4 digits + letters (2-4 letters)
So I wrote:
(setq recentf-exclude '(
/diary[0-9]\{4\}[a-zA-Z]\{2,4\}$
))
but without success, all the lines of my temp-diaries still appear in recentf.
Probably I should start the regex with something different than /, but I
tried everything I could think of, e.g. \\,
c:/Users/aw/AppData/Local/Temp/, without $ at the end...
As I'm running out of ideas, maybe you could give me a hint again.
Regards,
Alexander
Re: [O] minor mode recentf: show only *.tex and *.org files?!
Le 25/06/2013 14:30, AW a écrit :
(setq recentf-exclude '(
/diary[0-9]\{4\}[a-zA-Z]\{2,4\}$
))
You have to double the backslashes. Reason is that when lisp reads the
string, it translates it into
/diary[0-9]{4}[a-zA-Z]{2,4}$
which is not the regexp you want.
--
Nico.
Re: [O] minor mode recentf: show only *.tex and *.org files?!
Am Dienstag, 25. Juni 2013, 14:39:50 schrieb Nicolas Richard:
Le 25/06/2013 14:30, AW a écrit :
(setq recentf-exclude '(
/diary[0-9]\{4\}[a-zA-Z]\{2,4\}$
))
You have to double the backslashes. Reason is that when lisp reads the
string, it translates it into
/diary[0-9]{4}[a-zA-Z]{2,4}$
which is not the regexp you want.
I get lots of lines like c:/Users/aw/AppData/Local/Temp/diary1234ABc ,
despite duplication of backlashes.
Hm. Tried with leading / and without, same result. So I inserted a whole
filename including path instead of an regex and this failed as well. It seems
the whole recentf-exclude does not work, at least under windows 7. I created a
testfile Test.org and tried to exclude it in various ways, but without success.
Dammit. Can it be the leading /?
However, thank you for your very appreciated help!
Regards,
Alexander
[O] bug#14605: Problem with export an .org file to .pdf does not open pdf file
On 06/13/2013 03:28 PM, Petr Hracek wrote: Hi folks, I would like to export some .org file into .pdf file. This should also open PDF after export is done but it does not. This is done by command C-c C-e d. In some case emacs freezes. Could you please help me? Hi I have find out that if file org/org.el where are defined variables like org-file-apps is mentioned (\\.pdf\\' . default) When I changed them to e.g xpdf then pdf file is openned properly. -- Best regards / S pozdravem Petr Hracek
Re: [O] Slides about LaTeX export
Hi John,
John Hendy wrote:
On Jun 14, 2013 4:37 PM, Fabrice Niessen fni-n...@pirilampo.org wrote:
Just to let you know I've made a 1h30 presentation about the LaTeX exporter
of Org mode 8 at the Stage LaTeX de Dunkerque 2013, on last Wednesday
(12th of June).
My slides are visible on:
http://fr.slideshare.net/fniessen/org-modelatexexport
The Org source, LaTeX generated file and PDF output are on:
http://www.github.com/fniessen
Very nice!
Thanks!
Really nice overview of side by side translations between Org and LaTex.
Yes, I wanted to show the problem (horrible LaTeX syntax) and the solution
(just write what you meant, with almost no extra syntax in Org).
That made quite a shock to the attendants, even if they're used to the LaTeX
side: they were astonished that the Org syntax was so close to the how it's
displayed in the PDF -- mainly for the lists, but also for the tables.
Out of curiosity, why didn't the exponent and subscript examples get
rendered/converted on slide 22?
That's something I still haven't understood... The only one, and you spotted
it!
I tried all variations of ^:nil, ^:t and ^:{} but none translated the
super/sub-scripts correctly. A mystery that stays to be discovered...
Best regards,
Fabrice
--
Fabrice Niessen
Leuven, Belgium
Re: [O] minor mode recentf: show only *.tex and *.org files?!
Am Dienstag, 25. Juni 2013, 14:39:50 schrieb Nicolas Nicolas Richard:
Le 25/06/2013 14:30, AW a écrit :
(setq recentf-exclude '(
/diary[0-9]\{4\}[a-zA-Z]\{2,4\}$
))
You have to double the backslashes. Reason is that when lisp reads the
string, it translates it into
/diary[0-9]{4}[a-zA-Z]{2,4}$
which is not the regexp you want.
Maybe the description of the variable recentf-exclude should be amended:
The variable recentf-exclude has to be set before your require recentf.
When I put my setting before (require 'recentf), it works!
Regards,
Alexander
Re: [O] minor mode recentf: show only *.tex and *.org files?!
AW alexander.will...@t-online.de writes: I get lots of lines like c:/Users/aw/AppData/Local/Temp/diary1234ABc , despite duplication of backlashes. As you noticed in your next mesasge, you should activate recentf only after setting this variable. Alternatively, you can call (recentf-cleanup) after you set the variable. Sorry I didn't mention it, when testing I called recentf-cleanup without even thinking about it. For the record, I also looked at the variable recentf-exclude description and I see that you can also add predicates to it, hence my suggestion for only org and tex files could be very much simplified (at least de-obfuscated) by writing a small lisp function. -- Nico.
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
I didn't see an announcement that this was fixed... but I just pulled yesterday afternoon and it does appear to be fixed. I haven't changed .emacs and on fresh session with =C-a s word RET=, everything looks great. Just wanted to report my experience as feedback. Thanks! John On Fri, Jun 21, 2013 at 7:26 AM, Rainer Stengele rainer.steng...@online.de wrote: Am 12.06.2013 23:08, schrieb Bastien: Hi John, John Hendy jw.he...@gmail.com writes: Just wanted to follow up on this. I haven't been using =C-a s= a ton so it drifted off my radar, but recently needed to use it a lot and noticed this was still persisting. ... it's still on my radar too, I've just been overwhelmed by work and other stuff. I should have more time next week, sorry for the delay. Bastien, I pulled today and as expected am without colors. Any chance to get this solved any time soon? I wonder if there are not a many more users having the issue .. Thanks, Rainer
[O] feature request
Org-mode has proven tremendously useful in writing musical analyses, but it would also be nice to provide musical examples in plain text. Is there anything like this available? If not, I may try to do it myself. I'm finally getting my act together and finishing the Emacs Lisp Intro; but any help pointing me to the right examples, or the right conceptual frameworks would be much appreciate. Here is more or less what I would want: -- -- -- -- -- Pretend that is the staff. The user places the cursor on the staff, and therefore enters note entry mode. The note-entry function is passed three args: one for the note, two for the rhythmic value. So if the user presses F, F is passed as the first argument; if the user enters 8, 8 is passed as the second argument; if the user enters ., . is passed as the third argument. This produces a dotted 8th F note on the staff. The third argument is optional (since not all rhythmic values are dotted), and its value is nil by default. Anyway, that is a draft of what I would want. May already exist with slightly different functionality.
Re: [O] [RFC]: Uniform indentation for lists
Hi, the indentation rules for lists in Org are ancient, and I don't thing we want to break so many existing files. And we certainly cannot change the numbered bullets. The only thing I would accept is an option to enforce 3 space indentation on TAB, but the parser must read 2 space indentation as well. And, as Savayu points out, lists longer than 9 items will always be an issue. - Carsten On 24.6.2013, at 23:58, Jambunathan K kjambunat...@gmail.com wrote: This request is a result of adding Org-mode support to Oddmuse. (See my earlier mail that introduces Orgmuse). When lists are normalized, the sub-lists are introduced by varying amout of spaces depending on the type of the parent list. It's 3 spaces if the parent is numbered and 2 spaces if the parent is bulleted. 1. One 2. Two - Bullet One - Bullet Two 1. One 2. Two Oddmuse wiki and possibly Usemod (and even other Wiki engines) do a linear scan of text (much like what the old org-html.el used to do) and emits HTML by looking at thing at point. Having the list items introduced by varying amout of spaces makes the parser more stateful. I was wondering whether there would be some interest in 1) To eliminate the separators - . or ) - in the numbered list 2) Enhance the list repair routine so that it will alway indent by 3 spaces. With (1) above, the earlier list becomes, 1 One 2 Two - Bullet One - Bullet Two 1 One 2 Two This gives a uniform indentation of 2 spaces. With (2) or (3), the earlier list becomes, 1. One 2. Two - Bullet One - Bullet Two 1. One 2. Two This gives an indentation of 3 spaces. The 3 spaces could either be mandated by the canonical Org-markup spec or it could be ensured by the author of Org document himself (by using the proposed new repair option)
Re: [O] Bug: (bisected) org-meta-return makes an error at end of a buffer [8.0.3 (release_8.0.3-239-g269c5f @ /home/youngfrog/sources/org-mode/lisp/)]
Hello, Nicolas Richard theonewiththeevill...@yahoo.fr writes: Evalling (progn (switch-to-buffer org-test.org) (org-mode) (insert * good day\n) ; no \n implies no error. (setq debug-on-error t) (org-meta-return)) makes an error git bisect says: , | 3c933adaf627bc8a58cfefb62ff0f2d5df640673 is the first bad commit ` This should be fixed. Thank you for reporting this. Regards, -- Nicolas Goaziou
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
John, I pulled and am at commit ec8f3f987ec46044975557a352dd491f107ff60b Merge: d3ef263 95b16b1 Author: Nicolas Goaziou n.goaz...@gmail.com Date: Tue Jun 25 09:33:39 2013 +0200 but cannot find any improvement. Bringing back the #+SETUPFILE option leaves me without colors .. Cheers, Rainer Am 25.06.2013 17:09, schrieb John Hendy: I didn't see an announcement that this was fixed... but I just pulled yesterday afternoon and it does appear to be fixed. I haven't changed .emacs and on fresh session with =C-a s word RET=, everything looks great. Just wanted to report my experience as feedback. Thanks! John On Fri, Jun 21, 2013 at 7:26 AM, Rainer Stengele rainer.steng...@online.de wrote: Am 12.06.2013 23:08, schrieb Bastien: Hi John, John Hendy jw.he...@gmail.com writes: Just wanted to follow up on this. I haven't been using =C-a s= a ton so it drifted off my radar, but recently needed to use it a lot and noticed this was still persisting. ... it's still on my radar too, I've just been overwhelmed by work and other stuff. I should have more time next week, sorry for the delay. Bastien, I pulled today and as expected am without colors. Any chance to get this solved any time soon? I wonder if there are not a many more users having the issue .. Thanks, Rainer
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
Nicolas Richard theonewiththeevill...@yahoo.fr writes: Meanwhile, John Hendy reported that the issue is resolved for him, so maybe I notice the thread too late to be useful, otoh I don't see which commit solved the problem, so maybe luck is involved in his resolution. Well, I'm really curious to see if affected users can confirm it is solved... I didn't have time to fix it, and I'd be glad Luck did it for me! -- Bastien
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
On Tue, Jun 25, 2013 at 10:43 AM, Rainer Stengele rainer.steng...@online.de wrote: John, I pulled and am at commit ec8f3f987ec46044975557a352dd491f107ff60b Merge: d3ef263 95b16b1 Author: Nicolas Goaziou n.goaz...@gmail.com Date: Tue Jun 25 09:33:39 2013 +0200 but cannot find any improvement. Bringing back the #+SETUPFILE option leaves me without colors .. Oh boy. Somehow I commented out my #+setupfile line in my main .org file without remembering doing so. What a goof up on my part. Sorry for the noise; I confirm it's still a problem. Re-adding it brings back the issue. John Cheers, Rainer Am 25.06.2013 17:09, schrieb John Hendy: I didn't see an announcement that this was fixed... but I just pulled yesterday afternoon and it does appear to be fixed. I haven't changed .emacs and on fresh session with =C-a s word RET=, everything looks great. Just wanted to report my experience as feedback. Thanks! John On Fri, Jun 21, 2013 at 7:26 AM, Rainer Stengele rainer.steng...@online.de wrote: Am 12.06.2013 23:08, schrieb Bastien: Hi John, John Hendy jw.he...@gmail.com writes: Just wanted to follow up on this. I haven't been using =C-a s= a ton so it drifted off my radar, but recently needed to use it a lot and noticed this was still persisting. ... it's still on my radar too, I've just been overwhelmed by work and other stuff. I should have more time next week, sorry for the delay. Bastien, I pulled today and as expected am without colors. Any chance to get this solved any time soon? I wonder if there are not a many more users having the issue .. Thanks, Rainer
Re: [O] :session question -- and changes to #+Property: syntax
Hopefully the simpler solution which uses the existing value of `org-babel-current-src-block-location' will prove sufficient (once someone implements it that is...). I'll implement it and see if this seems more useful than the current behaviour. If it is, then we'll have to decide if that new behaviour replaces the old one or yet another header argument or option switches between old and new. I guess it could be arranged so that the old-style properties kept the old behaviour and the new-style properties followed the new… I've pushed this to master, with documentation and testing. Old style property-based header arguments keep the old behaviour of looking up the properties at the point of source block definition for backwards compatibility and are now deprecated. The new header-args[:lang] properties use the location of the call as recorded in `org-babel-current-src-block-location'. This is great, thanks. I now see that we had different things in mind when talking about the location used when evaluating header arguments, however both were required and are now implemented. You implemented location-specific look up of header argument properties, I just pushed up location-specific evaluation of elisp embedded in header arguments as shown in the attached example file. Thanks, * First :PROPERTIES: :CUSTOM_ID: one :END: #+name: heading-id #+begin_src emacs-lisp :var point=(point) :var loc=(format %S org-babel-current-src-block-location) (format property %S at %d really %s (org-entry-get point CUSTOM_ID) point loc) #+end_src #+RESULTS: heading-id : property one at 70 really 70 * Second :PROPERTIES: :CUSTOM_ID: two :END: Call with all header arguments at the point of execution #+call: heading-id(point=(point)) #+RESULTS: heading-id(point=(point)) : property two at 433 really #marker at 433 in header-eval-location.org #+call: heading-id() #+RESULTS: heading-id() : property two at 582 really #marker at 582 in header-eval-location.org Another call from a code block rather than a call line. #+begin_src emacs-lisp :var in=heading-id() in #+end_src #+RESULTS: : property two at 762 really 762 -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] feature request
42 147 writes: Org-mode has proven tremendously useful in writing musical analyses, but it would also be nice to provide musical examples in plain text. Is there anything like this available? Yes. Org-Babel supports Lilypond. It's magic. http://www.lilypond.org/ http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html Yours, Christian
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
Bastien b...@altern.org writes: John Hendy jw.he...@gmail.com writes: Just wanted to follow up on this. I haven't been using =C-a s= a ton so it drifted off my radar, but recently needed to use it a lot and noticed this was still persisting. ... it's still on my radar too, I've just been overwhelmed by work and other stuff. I should have more time next week, sorry for the delay. I just noticed this thread, which i think reports exactly the issue I reported here [this thread was before, but the title didn't catch my eyes -- sorry about that] 87zjuv2r79@yahoo.fr and more or less fixed here 87bo7ati0m@yahoo.fr (not sent as a patch because I'm unsure about it) Meanwhile, John Hendy reported that the issue is resolved for him, so maybe I notice the thread too late to be useful, otoh I don't see which commit solved the problem, so maybe luck is involved in his resolution. -- Nico.
[O] Where to report bugs, submit patches? (babel)
Where is the appropriate place to submit bug reports and/or patches for org mode, especially babel and code block execution errors? Thanks! Subhan -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] feature request
Christian Moe m...@christianmoe.com writes: 42 147 writes: Is there anything like this available? Yes. Org-Babel supports Lilypond. It's magic. http://www.lilypond.org/ http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html Somewhere in my old files, I have a reference to an Emacs mode for entering music visually in a kind of ASCII mode, written by Neil Jerram if I remember correctly. But this was before Han-Wen and Jan wrote Lilypond. Now that Lilypond exists, it is an immensely more interesting avenue, in my opinion. Neil code would be fairly oldish anyway. I never tried using both Org and Lilypond as suggested, but it looks like a very appealing idea, I should try it. Thanks for the suggestion. François
Re: [O] Where to report bugs, submit patches? (babel)
Subhan Tindall subhan.tind...@rentrakmail.com writes: Where is the appropriate place to submit bug reports and/or patches for org mode, especially babel and code block execution errors? Right here, on the mailing list. You might want to look into the function org-submit-bug-report And please provide backtraces! -- Nick
[O] evaluation context in call statements
FThe arguments to a `#+call' line are evaluated in the context of the called block and not the calling block. This seems like a bug to me. For example, in the following i would expect the `call' to return Call and not Source as the results: ╭ │ * Source │ #+name: message │ #+BEGIN_SRC elisp :var m=foo │ m │ #+END_SRC │ │ #+RESULTS: message │ : foo │ │ * Call │ #+call: message(m=(nth 4 (org-heading-components))) │ │ #+RESULTS: message(m=(nth 4 (org-heading-components))) │ : Source ╰ is there any way to reference the current context in a `call' line? rick
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: This is great, thanks. I now see that we had different things in mind when talking about the location used when evaluating header arguments, however both were required and are now implemented. Indeed. You implemented location-specific look up of header argument properties, I just pushed up location-specific evaluation of elisp embedded in header arguments as shown in the attached example file. Great, thank you. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] feature request
Hi François On Tue, Jun 25, 2013 at 6:29 PM, François Pinard pin...@iro.umontreal.ca wrote: Somewhere in my old files, I have a reference to an Emacs mode for entering music visually in a kind of ASCII mode, written by Neil Jerram if I remember correctly. I am very curios to see how this looked like and how it worked. With a quick search I was not able to find it. Michael
Re: [O] evaluation context in call statements
Rick Frankel writes: The arguments to a `#+call' line are evaluated in the context of the called block and not the calling block. This seems like a bug to me. For example, in the following i would expect the `call' to return Call and not Source as the results: Tody's your lucky day because Eric just fixed this. There's a bug with finding the #+RESULTS line though: --8---cut here---start-8--- * Babel LOC ** Source #+name: message #+BEGIN_SRC elisp :var m=foo m #+END_SRC #+RESULTS: message : foo ** Call 1 #+call: message(m=(nth 4 (org-heading-components))) #+RESULTS: message(m=(nth 4 (org-heading-components))) : Call 2 ** Call 2 #+call: message(m=(nth 4 (org-heading-components))) --8---cut here---end---8--- Executing Call#2 will update the #+RESULTS for Call#1 (or actually the first matching #+RESULTS cookie in the whole document). I'd think it should also start looking for the results line from the point of call. I don't really get why it does this, maybe Eric knows where to look. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] evaluation context in call statements
Achim Gratz writes: Rick Frankel writes: Your lucky day is becoming a streak. Executing Call#2 will update the #+RESULTS for Call#1 (or actually the first matching #+RESULTS cookie in the whole document). I'd think it should also start looking for the results line from the point of call. I don't really get why it does this, maybe Eric knows where to look. I'd think this should fix it. From 945d7d25a63077bae18c656768939f292b52bb44 Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Tue, 25 Jun 2013 21:51:07 +0200 Subject: [PATCH] ob-core: insert results at the point of call * lisp/ob-core.el (org-babel-execute-src-block): Ensure that head is set to location of call if it is known. Pass through head to `org-babel-find-named-result' so that it doesn't search from the beginning of the file. --- lisp/ob-core.el | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 4115912..36f42e1 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -662,8 +662,8 @@ (defun org-babel-execute-src-block (optional arg info params) (when (cdr (assoc :file params)) (setq result-params (remove file result-params) - (org-babel-insert-result - result result-params info new-hash indent lang)) + (org-babel-insert-result + result result-params info new-hash indent lang)) (run-hooks 'org-babel-after-execute-hook) result) (setq call-process-region @@ -1839,7 +1839,11 @@ (defun org-babel-where-is-src-block-result (optional insert info hash indent) ;; - return t if it is found, else return nil ;; - if it does not need to be rebuilt, then don't set end ;; - if it does need to be rebuilt then do set end - name (setq beg (org-babel-find-named-result name)) + name (setq beg (org-babel-find-named-result + name + (or org-babel-current-src-block-location + (nth 6 info) + (org-babel-where-is-src-block-head (prog1 beg (when (and hash (not (string= hash (match-string 5 (goto-char beg) (setq end beg) ;; beginning of result -- 1.8.3.1 Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] evaluation context in call statements
Achim Gratz writes: I'd think this should fix it. Please discard the first hunk of this patch. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] evaluation context in call statements
Hi Achim On Tue, Jun 25, 2013 at 9:53 PM, Achim Gratz strom...@nexgo.de wrote: Achim Gratz writes: Executing Call#2 will update the #+RESULTS for Call#1 (or actually the first matching #+RESULTS cookie in the whole document). I'd think it should also start looking for the results line from the point of call. I don't really get why it does this, maybe Eric knows where to look. I'd think this should fix it. Is it a bug? I also noticed this when I was writing an ERT. First it confused me but then I thought that this is intended to make it possible to have #+BEGIN_SRC and #+RESULT at independent locations, possibly in reverse order. For how to address several similar calls to different results see my ERT patch here http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73655 and the messages before. I used :session for emacs-lisp and a workaround with :var dummy_name for Babel languages that do not support :session like shell. Michael
Re: [O] evaluation context in call statements
Michael Brand writes: Is it a bug? I think so, but Eric has the last word on this. The results should come after the call, but the current implementation would look for the results line from the beginning of the buffer. I also noticed this when I was writing an ERT. First it confused me but then I thought that this is intended to make it possible to have #+BEGIN_SRC and #+RESULT at independent locations, possibly in reverse order. I can't see how it would be much more difficult to have a #+CALL where you want the result (independently of where the source block is), but it seems pretty limiting to allow only a single result. For how to address several similar calls to different results see my ERT patch here http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73655 and the messages before. I used :session for emacs-lisp and a workaround with :var dummy_name for Babel languages that do not support :session like shell. I didn't get what you were trying to do there, but it's pretty obvious now. Anyway, more testing shows my patch will prefer the results line after the call, but if you then insert another call before that (without an existing result) the result from the now second call will still be clobbered, so there needs to be some more fixing by limiting the search to not extend across other calls or source blocks. Or this really is a feature, although I don't really see much use for it. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] evaluation context in call statements
Achim Gratz writes: Anyway, more testing shows my patch will prefer the results line after the call, but if you then insert another call before that (without an existing result) the result from the now second call will still be clobbered, so there needs to be some more fixing by limiting the search to not extend across other calls or source blocks. Or this really is a feature, although I don't really see much use for it. If this feature turns out to be useful, how about a :target header argument to specify a named result block? Then it would also be possible to eliminate those rather unsightly appendices. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] [RFC]: Uniform indentation for lists
Jambunathan K writes: When lists are normalized, the sub-lists are introduced by varying amout of spaces depending on the type of the parent list. It's 3 spaces if the parent is numbered and 2 spaces if the parent is bulleted. 1. One 2. Two - Bullet One - Bullet Two 1. One 2. Two Oddmuse wiki and possibly Usemod (and even other Wiki engines) do a linear scan of text (much like what the old org-html.el used to do) and emits HTML by looking at thing at point. Having the list items introduced by varying amout of spaces makes the parser more stateful. I don't think this is ever going to work unless you restrict either the number of items or the types of enumeration. But you could easily normalize on export into those formats by indenting with a number of tabs corresponding to the indent level. That would look strange in a buffer (unless you set the tab-width appropriately), but it would be parseable more easily. But Oddmuse is in Perl, so keeping a stack of indents really isn't a big deal (and I don't think it'd be in other languages like Python, PHP or Ruby). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Right-to-left text in org mode
It turns out that org mode does force directionality in its buffers. I found in org.el the line 5308 (setq bidi-paragraph-direction 'left-to-right) However, bidi-paragraph-direction is always buffer local when set. That explains why switching to other mode does not help. The solution is to set bidi-paragraph-direction to nil in org buffers with mixed LTR and RTL texts. This, however, might change the alignment of some headings to right-aligned. But the bidi markers now work just fine, so it's just a matter of placing them wisely. I appreciate the time you took for this little discussion. It helped me get a clearer picture of the inner workings of bidi and emacs. Kind regards, Manuel GJT On Tue, Jun 25, 2013 at 2:03 AM, Dov Grobgeld dov.grobg...@gmail.comwrote: A work around seems to be to provide an empty line between the LTR and the RTL paragraph. I.e. instead of * this is ltr * THIS IS RTL do: * this is ltr * THIS IS RTL But you are correct that the wrapping of LTR paragraphs with RTL text is buggy. This bug seems to have nothing to do with org mode, but happens e.g. in text mode and fundamental mode as well. You should raise this issue on the emacs-list or file a bug with emacs. On Tue, Jun 25, 2013 at 7:27 AM, Manuel GJT valh...@gmail.com wrote: Specifically what additional information should I provide? This happens to me even without my .emacs loaded. I'm running Ubuntu 12.04 with m17n-(db/contrib), libm17n-(0/dev) installed. It seems that in org mode is forcing LTR in mixed-directionality texts since, for example, a heading with RTL text will not change the stars to be right-aligned, and the cursor's behavior in org mode is different than in a clean buffer. Perhaps you could show me how to ignore any previous paragraph settings other than with R-T-L MARK? Kind regards, Manuel GJT On Mon, Jun 24, 2013 at 12:49 PM, Dov Grobgeld dov.grobg...@gmail.com wrote: I was able to reproduce this behavior only with by forcing the paragraph direction to LTR or equivilantly by having a first strong LTR character in the beginning of the paragraph. Please provide more information about your environment, and someone might be able to help you. Regards, Dov On Mon, Jun 24, 2013 at 8:22 PM, Manuel GJT valh...@gmail.com wrote: Hello everyone, I need to work in an org buffer with both left-to-right and right-to-left text. Although the character directionality and composition works fine, when writing paragraphs with visual-line-mode on the lines get inverted, i.e., the line ZYX CBA appears as ZYX CBA instead of CBA ZYX The section 22.20 Bidirectional Editing of the Emacs manual suggests forcing the directionality of the paragraph with RIGHT-TO-LEFT MARK, but this does not seem to work: even with such a character beginning the line, (current-bidi-paragraph-direction) returns left-to-right. The RTL MARK seems to work just fine in tables. When written in a clean text-mode buffer the same text appears with proper directionality. However switching from org-mode to text-mode does not correct directionality in said paragraphs. The issue persists even when visiting the file with emacs -Q. org-version 8.0.3, same issue with v. 7.9.4 Your help is much appreciated. -- Manuel GJT -- Manuel GJT -- Manuel GJT
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
I pulled and tested around 8:00 AM EDT today (because I let myself get so far behind on commits that I couldn't tell if a fix had been pushed or not) and the problem still existed at that time. On Jun 25, 2013, at 11:52 AM, Bastien b...@altern.org wrote: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Meanwhile, John Hendy reported that the issue is resolved for him, so maybe I notice the thread too late to be useful, otoh I don't see which commit solved the problem, so maybe luck is involved in his resolution. Well, I'm really curious to see if affected users can confirm it is solved... I didn't have time to fix it, and I'd be glad Luck did it for me! -- Bastien
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
I had lost colors in some modes for some weeks (helm, wl) and yesterday with an updated org they came back. So for me it's fixed. El Tue, 25 Jun 2013 22:01:43 -0400 Mike McLean va escriure: I pulled and tested around 8:00 AM EDT today (because I let myself get so far behind on commits that I couldn't tell if a fix had been pushed or not) and the problem still existed at that time. On Jun 25, 2013, at 11:52 AM, Bastien b...@altern.org wrote: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Meanwhile, John Hendy reported that the issue is resolved for him, so maybe I notice the thread too late to be useful, otoh I don't see which commit solved the problem, so maybe luck is involved in his resolution. Well, I'm really curious to see if affected users can confirm it is solved... I didn't have time to fix it, and I'd be glad Luck did it for me! -- Bastien
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
On Jun 25, 2013 9:36 PM, Daniel Clemente n142...@gmail.com wrote: I had lost colors in some modes for some weeks (helm, wl) and yesterday with an updated org they came back. So for me it's fixed. Do you have a #+setupfile entry in your file? John El Tue, 25 Jun 2013 22:01:43 -0400 Mike McLean va escriure: I pulled and tested around 8:00 AM EDT today (because I let myself get so far behind on commits that I couldn't tell if a fix had been pushed or not) and the problem still existed at that time. On Jun 25, 2013, at 11:52 AM, Bastien b...@altern.org wrote: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Meanwhile, John Hendy reported that the issue is resolved for him, so maybe I notice the thread too late to be useful, otoh I don't see which commit solved the problem, so maybe luck is involved in his resolution. Well, I'm really curious to see if affected users can confirm it is solved... I didn't have time to fix it, and I'd be glad Luck did it for me! -- Bastien
Re: [O] feature request (rather off-topic)
Michael Brand michael.ch.br...@gmail.com writes: François Pinard pin...@iro.umontreal.ca wrote: Somewhere in my old files, I have a reference to an Emacs mode for entering music visually in a kind of ASCII mode, written by Neil Jerram if I remember correctly. I am very curios to see how this looked like and how it worked. With a quick search I was not able to find it. Hi, Michael. I looked around a bit, and found not much in my files. I cleaned up the GNU Music project many, many years ago and did not keep much of it. Even the Emacs mode (written by Neil Jerram unless I'm mistaken) did not survive for long in the project, as we (Neil included) selected another representation for music, still kind of 2-dimensional, but more compactly coded than an ASCII drawing. To edit this representation, instead of Emacs, we wrote a specialized curses-based program. I surprisingly still have scanner.l, parser.y, editor.c, and a few other files from that project, but really, this is of no interest nowadays. In my opinion, Lilypond is immensely more appealing! It seems that Neil Jerram, which sadly, I did not contact in ages, remained active in the Emacs communities, you should easily find him here and there by Googling. I see Neil Jerram nj...@cus.cam.ac.uk in http://stuff.mit.edu/afs/sipb/project/musictools/src/lilypond-2.6.3/AUTHORS.txt, but while I think unlikely that this address is still valid, I do not know. You might try to reach him there or otherwise, if you are curious enough: maybe that with some luck, he kept around some code or example? Let me share that I remember Neil as one of the most exquisite persons I ever worked with: it always has been a great pleasure. The GNU Music project underwent a long, dark episode when Richard Stallman forced a new direction and leadership upon us, seduced at the times by the promises of Robert Strandh, who brought the project into some moribund state. Han-Wen succeeded in getting the project back to life (I helped my best), to convey what later became Lilypond. Lilypond has been successful to the point GNU Music is never heard anymore by that name, and that's very OK: Lilypond goes much beyond our dreams and means. :-) The Lilypond musical notation is quite efficient. I often use it, with a pen on a sheet of paper, in the need of noting some music for myself, when away from home and any computer. For me, it's quicker than drawing staves and notes. I quite suspect that Lilypond notation, combined with the virtues of Babel, and the graphical capabilities of Emacs, might really be the best way to handle musical scores with Org. François
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
El Tue, 25 Jun 2013 21:42:39 -0500 John Hendy va escriure: On Jun 25, 2013 9:36 PM, Daniel Clemente n142...@gmail.com wrote: I had lost colors in some modes for some weeks (helm, wl) and yesterday with an updated org they came back. So for me it's fixed. Do you have a #+setupfile entry in your file? I had a #+setupfile in 6 of the .org files that make up my agenda. In addition, I always did this: emacsclient -n --eval '(org-agenda-list)' after opening emacs --daemon so that all files be opened and the agenda be prepared.
Re: [O] [RFC]: Uniform indentation for lists
Achim Gratz strom...@nexgo.de writes: I don't think this is ever going to work unless you restrict either the number of items or the types of enumeration. My item will most likely look this. 1. One 1. Two 1. Hundredth item 1. Thousandth item Works well both in Org and the Wiki engine. What I need is a way to suppress electric repair of Lists or have the repair work in restricted ways. But Oddmuse is in Perl, so keeping a stack of indents really isn't a big deal (and I don't think it'd be in other languages like Python, PHP or Ruby). True.
Re: [O] [RFC]: Uniform indentation for lists
Suvayu Ali fatkasuvayu+li...@gmail.com writes: I think it will still break for long lists (greater than 9 items). 9 item 10 item There wouldn't be any long lists. All items will be numbered 1.
Re: [O] evaluation context in call statements
Is it a bug? I think so, but Eric has the last word on this. The results should come after the call, but the current implementation would look for the results line from the beginning of the buffer. The current behavior is the expected behavior and is not a bug. That said, I don't believe the current behavior is necessarily the best behavior, rather it was the obvious choice at the time of implementation and there has never been a successful push to change it. I think we could be well served by discussing how people use call lines, how they would use call lines (if this behavior changed), and what behavior would best support these existing and potential use cases. In defense of the existing behavior, I don't see the benefit of calling a code block with the same arguments from multiple locations and subsequently littering a file with multiple identical results blocks. If we do want to change this behavior it would be nice to check the email list archives to see if/when the existing behavior has been defended in the past. Anyway, more testing shows my patch will prefer the results line after the call, but if you then insert another call before that (without an existing result) the result from the now second call will still be clobbered, so there needs to be some more fixing by limiting the search to not extend across other calls or source blocks. Or this really is a feature, although I don't really see much use for it. If this feature turns out to be useful, how about a :target header argument to specify a named result block? Then it would also be possible to eliminate those rather unsightly appendices. My only thought about a :target header argument is that it would need to be implemented for other types of code blocks as well, which could lead to very confusing behavior if we have a named code block with a :target header argument which differs from the name. Also, if the target is referenced, would the #+call line be re-run? My vote is for adding #+name support to call lines, and then handling their results in the same manner as code block results. -- Eric Schulte http://cs.unm.edu/~eschulte
[O] Change latex export to use cref
Is there a variable that can be set so that latex export uses \cref instead of \ref? Thanks, Derek
Re: [O] Change latex export to use cref
Derek Thomas derekctho...@gmail.com writes:
Is there a variable that can be set so that latex export uses \cref instead
of \ref? Thanks,
Adding the following to your config should work.
;; -*- emacs-lisp -*-
(defun org-latex-ref-to-cref (text backend info)
Use \\cref instead of \\ref in latex export.
(when (org-export-derived-backend-p backend 'latex)
(replace-regexp-in-string ref{ cref{ text)))
(add-to-list 'org-export-filter-final-output-functions
'org-latex-ref-to-cref)
Hope this helps,
--
Eric Schulte
http://cs.unm.edu/~eschulte
