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 mo
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
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,
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
AW 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$"
Am Dienstag, 25. Juni 2013, 12:34:12 schrieb Nicolas Nicolas Richard:
> AW 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 :
> (s
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.
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
> /
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
Hi John,
John Hendy wrote:
> On Jun 14, 2013 4:37 PM, "Fabrice Niessen" 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:
>>
>> ht
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
AW 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.
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, 20
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
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 a
Hello,
Nicolas Richard 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:
> ,
> | 3c933adaf627bc8a58cfefb62ff0f2d5df
John,
I pulled and am at
commit ec8f3f987ec46044975557a352dd491f107ff60b
Merge: d3ef263 95b16b1
Author: Nicolas Goaziou
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,
Nicolas Richard 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 ca
On Tue, Jun 25, 2013 at 10:43 AM, Rainer Stengele
wrote:
> John,
>
> I pulled and am at
>
> commit ec8f3f987ec46044975557a352dd491f107ff60b
> Merge: d3ef263 95b16b1
> Author: Nicolas Goaziou
> Date: Tue Jun 25 09:33:39 2013 +0200
>
> but cannot find any improvement.
> Bringing back the #+SETUPF
>>> 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 de
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/
Bastien writes:
> John Hendy 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 ot
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
Christian Moe 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
Subhan Tindall 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!
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 eli
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 prope
Hi François
On Tue, Jun 25, 2013 at 6:29 PM, François Pinard
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 wo
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 bec
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.
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
Hi Achim
On Tue, Jun 25, 2013 at 9:53 PM, Achim Gratz 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
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
> bu
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 th
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
>
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
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 wrote:
> Nicolas Richard writes:
>
>> Meanwhile, John Hendy
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 th
On Jun 25, 2013 9:36 PM, "Daniel Clemente" 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 esc
Michael Brand writes:
> François Pinard 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
El Tue, 25 Jun 2013 21:42:39 -0500 John Hendy va escriure:
>
> On Jun 25, 2013 9:36 PM, "Daniel Clemente" 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 ent
Achim Gratz 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 wa
Suvayu Ali 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.
>> 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 be
Is there a variable that can be set so that latex export uses \cref instead
of \ref? Thanks,
Derek
Derek Thomas 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 ex
Eric Schulte writes:
> 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.
I agree that this didn't make all that much sense in the past, b
47 matches
Mail list logo
