Re: [O] Problems with (defvar foo) and Emacs 23
Achim Gratz writes: > Nick Dokos writes: >> I assume that we are talking about the seven commits > > Yes, but likely not all of them (or all changes in them). The only > problematic ones are where a dynamically scoped variable is renamed and > there are a bunch of others that probably are OK. Let's have a particular look at the renaming of entry->org-entry. -- Bastien
Re: [O] Problems with (defvar foo) and Emacs 23
Achim Gratz writes:
> Bastien writes:
>> Well -- I'll be pretty busy next week, so hopefully we can fix this
>> soon... any help welcome! :)
>
> Ditto, but you do realize this will be horribly broken in Emacs 24?
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=08d9b466225fad7e4cacd593f5ec7d2a4cd878ff
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=c24fa194a62cbbc45fa1b58e39dac293a006a0c9
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=fcf13e02aa4bd056316cb7476b94aecf80738b47
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=9054ba39d085dc2910285a194ed2206b36875289
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=b689cbfb6c4d287d839ac3b0727497e5114995d8
are fine.
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=b46fa17a97ee050b5aeccffaa7323201fe491371
was problematic, as reported by Bernt, and I think I fixed it.
It leaves us with
http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=6cbf1f417222321a47848a7368427ba8a22fe3a5
which should be carefully reviewed/tested/amended.
> Anyway, for that single dynamic "state" variable: it is let-bound in
> org.el/org-todo and then dynamically scoped in many, many places:
>
> contrib/lisp/{org-{checklist,choose},org2rem}.el
>
> /lisp/{org-{agenda,clock,icalendar,mouse,taskjuggler},org}.el
The `state' dynamically scoped in these files is not necessarily the
same `state' that is dynamically scoped in `org-todo'.
For example in org-agenda.el there is `state' in `org-agenda-log-mode',
but this is dynamically scoped in another function org-agenda.el that
does not depend on org.el's definition for `state'...
> So the correct prefixed name should probably be org-todo-state (there
> are other such "state"s in other places, don't know yet if they are also
> dynamically scoped into other functions). You need to also keep track
> of which functions use "state" as a formal parameter name, since these
> shadow the dynamic variable from the outside, but provide another
> "state" for calls on the inside…
Yep -- I guess we're good for a fun ride.
> Haven't yet checked any of the other definitions that had their name
> changed, gotta fetch some sleep before work.
Please do!
Let's do some heavy testing against current HEAD and let's carefully
review code. But let's not panic -- Emacs is still in pretest, that's
the whole purpose of a pretest.
Thanks all for your help,
--
Bastien
Re: [O] [URGENT] Problems with (defvar foo) and Emacs 23
Achim Gratz writes: > Achim Gratz writes: >> Again, the missing value is not the problem. The problem arises when >> the variable name in the caller and the callee becomes different. I'll >> let Bastien and Martyn sort that one out... :-) > > The expedient fix would likely be to chose the same prefix for all the > others (dyn/org-…?), We need to use org- as a prefix. org-dyn is a good candidate but let's check in other packages if there is a convention about this. > but all local bindings in all functions using these > would also need to change. Since this is probably going to be a lot of > work, perhaps one could comment out those defvars were the variable > isn't actually global (like "state") and deal only with the remaining > ones if any. Not sure I understand (it's quite early in the morning...) - can you explain this? -- Bastien
Re: [O] Problems with (defvar foo) and Emacs 23
Achim Gratz writes: > Bernt Hansen writes: >> I can see the variable in the source defined as >> >> lisp/org-clock.el:(defvar org-clock-state) ;; dynamically scoped into this >> function >> >> but I don't get a variable definition with this code in emacs 23.2.1. > > You aren't supposed to get one, as this should have been pulling in a > local variable defined elsewhere (from within another function). > >> If I change the definition to >> >> (defvar org-clock-state nil) >> >> then it works for me. > > Yes, but the bug introduced by renaming the variable is still there. > You do get a variable, but not the one you're supposed to be scoping. I fixed the problem with `org-clock-state'. This should be `org-state'. `state' is a local variable in many org.el functions, I renamed it to `org-state' in org-clock.el and in "caller" sexp from org.el. > Again, the missing value is not the problem. The problem arises when > the variable name in the caller and the callee becomes different. I'll > let Bastien and Martyn sort that one out... :-) Let's sort this out by slowly fixing problems that we can spot. -- Bastien
Re: [O] Problems with (defvar foo) and Emacs 23
Nick Dokos writes: > There is (supposed to be) *one* place somewhere that actually defines > it: > > (defvar foo 1) ... unless foo is dynamically bound into a "caller" sexp. -- Bastien
Re: [O] bug in done on repeating task
On 2012-04-01, Bastien wrote: > This has been reported and should be fixed already. Can you confirm? seems fixed. thank you, bastien. samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] BUG: Unable to compile on Master
On 2012-04-01, Bastien wrote: >> same in 22 > > Fixed. Please try again. yes, thank you, bastien. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Problems with (defvar foo) and Emacs 23
Achim Gratz wrote: > Nick Dokos writes: > > I assume that we are talking about the seven commits > > Yes, but likely not all of them (or all changes in them). The only > problematic ones are where a dynamically scoped variable is renamed and > there are a bunch of others that probably are OK. > Agreed, but the point is that each and every variable renaming will need to be checked in the light of these criteria. Bugs like this have the potential of creating havoc for a long time to come. It may be easier to start from a working state than to try to fix the current broken state piecemeal. Besides, I'd rather have a single commit in the history that does the right thing: having one commit that creates the initial buggy state and then N commits at various times to fix the brokenness might create all sorts of problems (breaking bisectability e.g.) Nick > > $ git log --oneline -100 | grep 'Fix global' > > 6cbf1f4 Fix global dynamic variables in org-agenda.el and org.el. > > b689cbf Fix global dynamic variables in org-table.el. > > 9054ba3 Fix global dynamic variables in org-special-blocks.el. > > b46fa17 Fix global dynamic variables in org-clock.el. > > 08d9b46 Fix global dynamic variables prefixes in org-bibtex.el. > > c24fa19 Fix global dynamic variables prefixes in org-mouse.el. > > fcf13e0 Fix global dynamic variables prefixes in org-beamer.el. > > > > I tried reverting these in a branch: I had to merge lisp/org.el by hand > > while reverting the first one, but the rest went through without any > > problems. > > > > Does that seem like the right thing to do for now then? > > For Emacs 24, it is probably the right thing to do, depending on how > much time there is left before release. In hotfix/master the changes > should be corrected so that they do what they were supposed to do > (i.e. also rename the variables in the caller). > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > Wavetables for the Waldorf Blofeld: > http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables > >
Re: [O] BUG: Unable to compile on Master
Nick Dokos writes: > Bastien wrote: > >> Samuel Wales writes: >> >> > same in 22 >> >> Fixed. Please try again. >> >> Thanks, >> >> -- >> Bastien >> > > Fix confirmed (on emacs24, but that's probably irrelevant). Yes, it is relevant, as the bug was coming from a misformed sexp (a leftover from a merge.) Thanks for double-checking! -- Bastien
Re: [O] BUG: Unable to compile on Master
Bastien wrote: > Samuel Wales writes: > > > same in 22 > > Fixed. Please try again. > > Thanks, > > -- > Bastien > Fix confirmed (on emacs24, but that's probably irrelevant). Nick
Re: [O] bug in done on repeating task
Hi Samuel, Samuel Wales writes: > let*: Symbol's value as variable is void: org-last-state This has been reported and should be fixed already. Can you confirm? Thanks a lot, -- Bastien
Re: [O] BUG: Unable to compile on Master
Samuel Wales writes: > same in 22 Fixed. Please try again. Thanks, -- Bastien
Re: [O] Problems with (defvar foo) and Emacs 23
Nick Dokos writes: > I assume that we are talking about the seven commits Yes, but likely not all of them (or all changes in them). The only problematic ones are where a dynamically scoped variable is renamed and there are a bunch of others that probably are OK. > $ git log --oneline -100 | grep 'Fix global' > 6cbf1f4 Fix global dynamic variables in org-agenda.el and org.el. > b689cbf Fix global dynamic variables in org-table.el. > 9054ba3 Fix global dynamic variables in org-special-blocks.el. > b46fa17 Fix global dynamic variables in org-clock.el. > 08d9b46 Fix global dynamic variables prefixes in org-bibtex.el. > c24fa19 Fix global dynamic variables prefixes in org-mouse.el. > fcf13e0 Fix global dynamic variables prefixes in org-beamer.el. > > I tried reverting these in a branch: I had to merge lisp/org.el by hand > while reverting the first one, but the rest went through without any > problems. > > Does that seem like the right thing to do for now then? For Emacs 24, it is probably the right thing to do, depending on how much time there is left before release. In hotfix/master the changes should be corrected so that they do what they were supposed to do (i.e. also rename the variables in the caller). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] BUG: Unable to compile on Master
same in 22 On 2012-04-01, Ezequiel Birman wrote: >> "JL" == Jonathan Leech-Pepin writes: > > > Hello Org, Using current git master I get the following error when > > running: , | make clean && make && make info ` > > > Error , | In toplevel form: | lisp/org-ascii.el:29:1:Error: > > Invalid function: "body" | Makefile:484: recipe for target > > `lisp/org-ascii.elc' failed | make: *** [lisp/org-ascii.elc] Error > > 1 ` > > > I was able to successfully compile Org with commit: 829285e > > (ensure noweb expanded body is used on export) > > Same here > > -- > Ezequiel Birman > > > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] BUG: Unable to compile on Master
> "JL" == Jonathan Leech-Pepin writes: > Hello Org, Using current git master I get the following error when > running: , | make clean && make && make info ` > Error , | In toplevel form: | lisp/org-ascii.el:29:1:Error: > Invalid function: "body" | Makefile:484: recipe for target > `lisp/org-ascii.elc' failed | make: *** [lisp/org-ascii.elc] Error > 1 ` > I was able to successfully compile Org with commit: 829285e > (ensure noweb expanded body is used on export) Same here -- Ezequiel Birman
Re: [O] Problems with (defvar foo) and Emacs 23
Achim Gratz wrote:
> Bastien writes:
> > Well -- I'll be pretty busy next week, so hopefully we can fix this
> > soon... any help welcome! :)
>
> Ditto, but you do realize this will be horribly broken in Emacs 24?
>
> Anyway, for that single dynamic "state" variable: it is let-bound in
> org.el/org-todo and then dynamically scoped in many, many places:
>
> contrib/lisp/{org-{checklist,choose},org2rem}.el
>
> /lisp/{org-{agenda,clock,icalendar,mouse,taskjuggler},org}.el
>
> So the correct prefixed name should probably be org-todo-state (there
> are other such "state"s in other places, don't know yet if they are also
> dynamically scoped into other functions). You need to also keep track
> of which functions use "state" as a formal parameter name, since these
> shadow the dynamic variable from the outside, but provide another
> "state" for calls on the inside…
>
> Haven't yet checked any of the other definitions that had their name
> changed, gotta fetch some sleep before work.
>
>
I assume that we are talking about the seven commits
$ git log --oneline -100 | grep 'Fix global'
6cbf1f4 Fix global dynamic variables in org-agenda.el and org.el.
b689cbf Fix global dynamic variables in org-table.el.
9054ba3 Fix global dynamic variables in org-special-blocks.el.
b46fa17 Fix global dynamic variables in org-clock.el.
08d9b46 Fix global dynamic variables prefixes in org-bibtex.el.
c24fa19 Fix global dynamic variables prefixes in org-mouse.el.
fcf13e0 Fix global dynamic variables prefixes in org-beamer.el.
I tried reverting these in a branch: I had to merge lisp/org.el by hand
while reverting the first one, but the rest went through without any
problems.
Does that seem like the right thing to do for now then?
Nick
[O] BUG: Unable to compile on Master
Hello Org, Using current git master I get the following error when running: , | make clean && make && make info ` Error , | In toplevel form: | lisp/org-ascii.el:29:1:Error: Invalid function: "body" | Makefile:484: recipe for target `lisp/org-ascii.elc' failed | make: *** [lisp/org-ascii.elc] Error 1 ` I was able to successfully compile Org with commit: 829285e (ensure noweb expanded body is used on export) I've tested this on 2 separate machines as well as a clean pull into a separate directory. Regards, Jonathan
Re: [O] Feature request for noweb mode that strips references on export
On Sat, Mar 31, 2012 at 4:32 PM, Eric Schulte wrote: > > Thanks for bringing this problem to light. I've just pushed up a fix. > > Cheers, > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/ Thanks! This is really useful. Regards, Sean
[O] ATTR_HTML for a clickable image, howto?
Hello, Org mode friends. I just got a slight difficulty for which some of you may have an advice. My source looks like this: --8<---cut here---start->8--- #+ATTR_HTML: align="right" [[file:2011-06-04-gazou-passeport.png][file:2011-06-04-gazou-passeport-petit.jpg]] --8<---cut here---end--->8--- and once converted to HTML, yields (reformatted for legibility): --8<---cut here---start->8--- --8<---cut here---end--->8--- The ATTR_HTML details got applied to the tag while I wanted them to be on the tag. If I hand-edit the result so it is: --8<---cut here---start->8--- --8<---cut here---end--->8--- then I get the display I wanted. Is there a way for having #+ATTR_HTML to be applied to the inner tag instead of the outer one? François
Re: [O] Problems with (defvar foo) and Emacs 23
Bastien writes:
> Well -- I'll be pretty busy next week, so hopefully we can fix this
> soon... any help welcome! :)
Ditto, but you do realize this will be horribly broken in Emacs 24?
Anyway, for that single dynamic "state" variable: it is let-bound in
org.el/org-todo and then dynamically scoped in many, many places:
contrib/lisp/{org-{checklist,choose},org2rem}.el
/lisp/{org-{agenda,clock,icalendar,mouse,taskjuggler},org}.el
So the correct prefixed name should probably be org-todo-state (there
are other such "state"s in other places, don't know yet if they are also
dynamically scoped into other functions). You need to also keep track
of which functions use "state" as a formal parameter name, since these
shadow the dynamic variable from the outside, but provide another
"state" for calls on the inside…
Haven't yet checked any of the other definitions that had their name
changed, gotta fetch some sleep before work.
HTH,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Problems with (defvar foo) and Emacs 23
Nick Dokos writes: > Bernt Hansen wrote: > >> Hi Bastien, >> >> I updated to master today e917477 ((org-xhtml.el): Removed, 2012-04-01) >> and am getting errors about org-clock-last-state not defined in my GNU >> Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on >> raven, modified by Debian >> >> I can see the variable in the source defined as >> >> lisp/org-clock.el:(defvar org-clock-state) ;; dynamically scoped into this >> function >> >> but I don't get a variable definition with this code in emacs 23.2.1. >> >> If I change the definition to >> >> (defvar org-clock-state nil) >> >> then it works for me. >> >> There are _lots_ of these types of definitions with no value in the >> org-mode source. >> > > They are not supposed to *define* a variable. They are there to tell the > compiler not to worry. They are somewhat similar[fn:1] to extern declarations > in C code: whoever needs to use the variable says > > (defvar foo) > > There is (supposed to be) *one* place somewhere that actually defines > it: > > (defvar foo 1) > > Nick > > Footnotes: > > [fn:1] ...for some value of "similar". You have to take this with the > appropriately sized grain of salt. Ah, I had no idea how this was actually supposed to work :) Thanks for the clarification. I'll rewind to an older commit for now that works for me ... since I need it at work tomorrow. Thanks, Bernt
Re: [O] Problems with (defvar foo) and Emacs 23
Bernt Hansen wrote: > Hi Bastien, > > I updated to master today e917477 ((org-xhtml.el): Removed, 2012-04-01) > and am getting errors about org-clock-last-state not defined in my GNU > Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on > raven, modified by Debian > > I can see the variable in the source defined as > > lisp/org-clock.el:(defvar org-clock-state) ;; dynamically scoped into this > function > > but I don't get a variable definition with this code in emacs 23.2.1. > > If I change the definition to > > (defvar org-clock-state nil) > > then it works for me. > > There are _lots_ of these types of definitions with no value in the > org-mode source. > They are not supposed to *define* a variable. They are there to tell the compiler not to worry. They are somewhat similar[fn:1] to extern declarations in C code: whoever needs to use the variable says (defvar foo) There is (supposed to be) *one* place somewhere that actually defines it: (defvar foo 1) Nick Footnotes: [fn:1] ...for some value of "similar". You have to take this with the appropriately sized grain of salt.
Re: [O] [URGENT] Regression in `org-todo'
Bastien writes: > Moritz Ulrich writes: > >> Marking it URGENT as the release for emacs 24 seems to be affected >> too. > > Fixed, thanks. Fixed in Emacs too -- this will be fixed in the next minor release of Org, this is in hotfix/master in the meantime. Thanks, -- Bastien
Re: [O] Problems with (defvar foo) and Emacs 23
Achim Gratz writes: > Again, the missing value is not the problem. The problem arises when > the variable name in the caller and the callee becomes different. I'll > let Bastien and Martyn sort that one out... :-) Well -- I'll be pretty busy next week, so hopefully we can fix this soon... any help welcome! :) -- Bastien
Re: [O] [URGENT] Problems with (defvar foo) and Emacs 23
Achim Gratz writes: > Again, the missing value is not the problem. The problem arises when > the variable name in the caller and the callee becomes different. I'll > let Bastien and Martyn sort that one out... :-) The expedient fix would likely be to chose the same prefix for all the others (dyn/org-…?), but all local bindings in all functions using these would also need to change. Since this is probably going to be a lot of work, perhaps one could comment out those defvars were the variable isn't actually global (like "state") and deal only with the remaining ones if any. HTH, 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] [URGENT] Regression in `org-todo'
Moritz Ulrich writes: > Marking it URGENT as the release for emacs 24 seems to be affected > too. Fixed, thanks. -- Bastien
Re: [O] About org-babel menu
Bernt Hansen wrote: > Nick Dokos writes: > > > One possible gotcha: in my case, C- is undefined, even though > > the docs say it should be. I tried emacs -q and emacs -Q as well, just > > in case, my init somehow clobbers it: undefined there as well. So I > > have to bind it somehow: > > > >(global-set-key [C-mouse-3] 'mouse-popup-menubar-stuff) > > > > does not seem to work for me, but > > > >(global-set-key [mouse-3] 'mouse-popup-menubar-stuff) > > > > does. > > > > GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of > > 2012-01-24 > > > > That's good enough I guess but I was wondering if anybody else has these > > problems. > > GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 > on raven, modified by Debian > > [C-mouse-3] works for me and I've never customized it to my knowledge. > I also have the menus turned off. Maybe it's an emacs 24 thing? > It might very well be. Thanks for checking! Nick
Re: [O] Problems with (defvar foo) and Emacs 23
Bernt Hansen writes: > I can see the variable in the source defined as > > lisp/org-clock.el:(defvar org-clock-state) ;; dynamically scoped into this > function > > but I don't get a variable definition with this code in emacs 23.2.1. You aren't supposed to get one, as this should have been pulling in a local variable defined elsewhere (from within another function). > If I change the definition to > > (defvar org-clock-state nil) > > then it works for me. Yes, but the bug introduced by renaming the variable is still there. You do get a variable, but not the one you're supposed to be scoping. > There are _lots_ of these types of definitions with no value in the > org-mode source. Again, the missing value is not the problem. The problem arises when the variable name in the caller and the callee becomes different. I'll let Bastien and Martyn sort that one out... :-) 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] is there a way to have =var_name= in table
Excellent. Thank you. On Sat, Mar 31, 2012 at 3:47 PM, Carsten Dominik wrote: > > On 31.3.2012, at 21:24, Stephen J. Barr wrote: > >> Dear org-mode list, >> >> Quick and easy question: >> >> I want to make a document that has a table where one column has >> variables and another column has descriptions. >> >> E.g. >> >> | VAR NAMES | DESC | >> |---+| >> | =var1= | this is the first var | >> | =var2= | this is the second var | >> | | | >> |---+| >> However, pressing [TAB] after writing =var1= causes #ERROR to show up. >> How do I make this work the way I am intending? :) > > > | VAR NAMES | DESC | > |---+| > | ~var1~ | this is the first var | > | ~var2~ | this is the second var | > | | | > |---+| > > - Carsten >
[O] Ukrainian language export strings (patch attached)
Dear Org-mode developers,
I want to send you a little patch containing the export strings (like
"Author", "Table of Contents" etc.) for Ukrainian.
Hope it can be useful.
All best,
Yury
diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index 1ce..3752f66 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -207,6 +207,9 @@ This option can also be set with the +OPTIONS line, e.g. \"-:nil\"."
("ru" "Автор" "Дата" "Содержание" "Сноски")
("sv" "Författare" "Datum" "Innehåll" "Fotnoter")
;; Use numeric character entities for proper rendering of non-UTF8 documents
+;; ("uk" "Автор" "Дата" "Зміст" "Примітки")
+("uk" "Автор" "Дата" "Зміст" "Примітки")
+;; Use numeric character entities for proper rendering of non-UTF8 documents
;; ("zh-CN" "作者" "日期" "目录" "脚注")
("zh-CN" "作者" "日期" "目录" "脚注")
;; Use numeric character entities for proper rendering of non-UTF8 documents
[O] bug#9809: 24.0.90; flyspell-auto-correct-word hard to access in org-mode
Bastien Guerry writes: > Glenn Morris writes: > >> Eric Hanchrow wrote: >> >>> I started emacs with "emacs -Q". Then I typed >>> >>> M-x o r g - m o d e M-x f l y s p e l l - >>> m o d e C-h c C-h c M-TAB >>> >>> C-h c showed me " runs the command pcomplete". >>> C-h c M-TAB (which I typed via Ctrl+Alt+i) showed me "M-TAB runs the >>> command flyspell-auto-correct-word". >>> >>> I expected _both_ key events -- and M-TAB -- to show me >>> flyspell-auto-correct-word. >> >> This occurs because org.el for some reason tries to define the M-TAB key >> 3 different ways: >> >> (org-defkey org-mode-map [(meta tab)] 'pcomplete) >> (org-defkey org-mode-map "\M-\t" 'pcomplete) >> (org-defkey org-mode-map "\M-\C-i" 'pcomplete) >> >> Removing all but the second definition would fix this. >> >> Ref "Named ASCII Control Characters" in the lispref. >> >> If you do not want to distinguish between (for example) and >> `C-i', make just one binding, for the ASCII character (octal >> code 011). If you do want to distinguish, make one binding for this >> ASCII character, and another for the "function key" `tab'. > > Thanks. This is now fixing in Org repo, I'll close the bug when > this goes into Emacs. Fixed in Emacs trunk. Closing this bug. -- Bastien
[O] bug#11110: bug with org-mode-hook and text-scale-set
Du Yanning writes:
> org-mode 7.8.03
> emacs 23.3, 23.4, 24.0.94
>
> steps to recreate:
>
> emacs -q
>
> copy the following code and paste it into the *scratch* buffer:
> (add-to-list 'auto-mode-alist '("\\.txt\\'" . org-mode))
> (add-hook 'org-mode-hook '(lambda () (text-scale-set 4)))
>
> M-x eval-buffer
>
> then C-x C-f to open a .txt file, and then C-x C-f to open another
> .txt file.
> Every time a .txt is opened, the font size become larger and larger.
> However, the indicator in the mode line remains +4.
This is now fixed in Emacs trunk. Thanks.
--
Bastien
[O] Problems with (defvar foo) and Emacs 23
Hi Bastien, I updated to master today e917477 ((org-xhtml.el): Removed, 2012-04-01) and am getting errors about org-clock-last-state not defined in my GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian I can see the variable in the source defined as --8<---cut here---start->8--- lisp/org-clock.el:(defvar org-clock-state) ;; dynamically scoped into this function --8<---cut here---end--->8--- but I don't get a variable definition with this code in emacs 23.2.1. If I change the definition to --8<---cut here---start->8--- (defvar org-clock-state nil) --8<---cut here---end--->8--- then it works for me. There are _lots_ of these types of definitions with no value in the org-mode source. --8<---cut here---start->8--- bernt@gollum:~/git/org-mode$ git grep '(defvar [a-z-]*)' | wc -l 409 --8<---cut here---end--->8--- Regards, Bernt
Re: [O] org-mime-htmlize: visual representation (thunderbird)
> > yes and no: latexit can do what you describe (and the author admits > that it only makes sense for documents whose size does not exceed one > page. latexit can also embed in html pages latex formulas, however > only $$ are allowed no equations (which makes it inferior to > org-preview-latex-fragments) > > In any case I attached the wrong eml file (the one with just one page) > I now attach the eml with the embedded formula. Maybe some useful > information can be extracted. > I'm not clear on how this differs from the messages produced using org-mime-htmlize, and it has been a while since I've looked into email mime mechanics. However, since the emails generated using org-mime-htmlize display correctly in Gmail and in gnus I'm inclined to say that this is a Thunderbird issue and leave it for them to debug. Sorry I'm not more helpful, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [URGENT] Regression in `org-todo'
Marking it URGENT as the release for emacs 24 seems to be affected too. On Sun, Apr 1, 2012 at 17:01, Moritz Ulrich wrote: > Commit 6cbf1f417222321a47848a7368427ba8a22fe3a5 renames variable > `last-state' to `org-last-state' in org.el. This change isn't > reflected in function `org-todo'. > > That causes the following regression: Toggling a TODO state to DONE on > a headline via C-c C-t (`org-todo') results in: "Symbol's value as > variable is void: org-last-state". > This is reproducible in latest HEAD and even in tag 'release_7.8.07'. > > M-x emacs-version: GNU Emacs 24.0.94.1 (i386-apple-darwin11.3.0, NS > apple-appkit-1138.32) of 2012-03-12 on moritz-macbook.local > > The attached patch contains a simple (two line) fix. > > > Cheers, > Moritz Ulrich > > -- > Moritz Ulrich -- Moritz Ulrich
Re: [O] URGENT Bug with exporting org source block
Eric Schulte writes: > I've just pushed up a fix for this. After looking into the code I'm > now not sure why it was working at all... Heh… > but I suppose all that matters is that it is working now. Fix confirmed. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [PATCH] link descriptions in :file results of src blocks
Eric Schulte writes: > Andreas Leha writes: > >> Eric Schulte writes: >> >>> [...] > I would like to apply this patch, however I have some questions about > the use of the :file argument and the result itself to fill in the > description if the :filelinkdescr header argument is left blank. Also, > I would suggest that :file-desc is a better name for this header > argument. Hi Eric, thanks for considering this patch. Feel free to change the term to anything more appropriate. > > In my opinion using the :file argument as a description changes (or at > least adds to) the meaning of the :file header argument. Is there a > significant benefit to this behavior? If not I'd prefer that an empty > :file-desc header argument have no effect. My original use case was indeed making a code block to produce [[file.pdf][file.pdf]] instead of [[file.pdf]] (see http://permalink.gmane.org/gmane.emacs.orgmode/53941). So, if you remove the possibility to specify an empty :file-desc, for me that would mean to give the file name twice, as in : #+begin_src R :results graphics :file test2.png :file-desc test2.png which would be avoidable with my proposed behaviour. I could live with that, though I'd still prefer not to have to type more than necessary... >>> >>> Makes sense, I've just pushed up a solution which builds on your initial >>> patch by >>> >>> 1. changing :filelinkdescr to :file-desc >>> >>> 2. when an empty :file-desc header argument is specified it's value is >>>set to the value of the file path resulting in >>>[[file.pdf][file.pdf]] >>> >>> 3. adding documentation and a test case >>> >>> Please let me know if this misses any part of your intended use case. >>> >>> Thanks for the contribution! >> >> Hi Eric, >> >> I seem not to be able to see that push. My git log contains only >> , >> | 8d43aa2 test the new file-desc header argument >> | 670c7f3 simplified implementation of :file-desc header argument >> | 1193844 documentation for the new file-desc header argument >> | 59800b2 change name of filelinkdescr to file-desc >> | a58a4f0 new source block header argument :filelinkdescr >> ` >> and indeed, the functionality you describe in 2. seems not to be >> available. What did I miss? >> > > Hi Andreas, > > The commit implementing the behavior described in (2) is 670c7f3. > Please take a look at the test-ob/file-desc-header-argument test case. > If it is passing on your system (as it is on mine) then the behavior > described in (2) is in fact implemented. > > Best, > Hi Eric, I tested with a wrong version of org-mode. It works in fact as expected. Thanks for your work on this one and sorry for the fake alarm. Regards, Andreas
Re: [O] URGENT Bug with exporting org source block
Achim Gratz writes: > Eric Schulte writes: >>> With your latest changes I get this test regression (I have not checked >>> which commit is responsible): >>> >> >> This is odd. The first time I ran the test suite this test failed for >> me as well, however on all subsequent runs of the test suite this test >> passed, and manually looking through the test the code indeed does seem >> to be acting as it should. > > This, together with the fact that I'll always start the test from a > fresh 'emacs -Q' would hint at some variable that needs declaration or > some other newly introduced dependency. Do you have an idea what to > look for? > I've just pushed up a fix for this. After looking into the code I'm now not sure why it was working at all... but I suppose all that matters is that it is working now. Thanks for the report, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] URGENT Bug with exporting org source block
Eric Schulte writes: > This is odd. The first time I ran the test suite this test failed for > me as well, however on all subsequent runs of the test suite this test > passed, and manually looking through the test the code indeed does seem > to be acting as it should. I can confirm that it runs through when I force emacs to run the test two times in succession. However, this seems to be a fluke really. The test failure is related to the fact that the test file has two different definitions for noweb-example1 and noweb-example2 and there is also a call to noweb-example that doesn't have a definition at all. Why all that ends up with test-point == nil I don't know... Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
[O] Date parsing silent failure / german dates
Hi all, it seem org-mode has some support for dates of the form dd.mm.[]. This is a popular notation in germany and probably elsewhere, but the support is undocumented and apparently very limited. For example, 06.03. => 2012-06-03 but adding a time like 03.06. 17:00 => today's date This latter case seems equivalent to shub shub => today's date So for me, as I like the notation, perhaps it could be fixed to allow for dates + times? Alternatively, the silent failure seems dangerous and should be removed. I'm OK with accepting no input as today, but non-parseable input shouldn't be accepted. I'm looking into this, but I don't think I'm likely to come up with a fix. Cheers, Simon
Re: [O] About org-babel menu
Nick Dokos writes: > One possible gotcha: in my case, C- is undefined, even though > the docs say it should be. I tried emacs -q and emacs -Q as well, just > in case, my init somehow clobbers it: undefined there as well. So I > have to bind it somehow: > >(global-set-key [C-mouse-3] 'mouse-popup-menubar-stuff) > > does not seem to work for me, but > >(global-set-key [mouse-3] 'mouse-popup-menubar-stuff) > > does. > > GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of > 2012-01-24 > > That's good enough I guess but I was wondering if anybody else has these > problems. GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian [C-mouse-3] works for me and I've never customized it to my knowledge. I also have the menus turned off. Maybe it's an emacs 24 thing? Regards, Bernt
Re: [O] Python code block hangs with :session if python-mode is loaded
At some point I tried IPython under emacs in windows and had some problems. >From what Eric is saying they may be similar to this http://lists.gnu.org/archive/html/help-gnu-emacs/2011-05/msg00291.html https://bugs.launchpad.net/ipython/+bug/290228
Re: [O] Python code block hangs with :session if python-mode is loaded
> The above executes without problem for me regardless of whether python- > mode has been explicitly loaded. I have python mode py-version "5.1.0" on > my machine. My guess is that python-mode changed the session prompt in > such a way that Babel can not tell when execution has completed. I have > the following in my *Python* session buffer after execution [1], what are > the contents of your *Python* session buffer after you have C-g'd out of the > loop? > > Best, > > Footnotes: > [1] *Python* > >>> print "%d + %d = %d" % (2, 3, 2+3) > 2 + 3 = 5 > 2**5 > >>> > 32 > >>> > >>> > >>> 'org_babel_python_eoe' > >>> 'org_babel_python_eoe' > >>> print "%d + %d = %d" % (2, 3, 2+3) > 2 + 3 = 5 > >>> 2**5 > 32 > >>> > >>> > >>> > >>> 'org_babel_python_eoe' > 'org_babel_python_eoe' > >>> > -- > Eric Schulte > http://cs.unm.edu/~eschulte/ Hi Eric. I'm using python-mode 6.0.6, and have it set up to use ipython as the default python shell. Here's what I see: -- Enthought Python Distribution -- www.enthought.com Python 2.7.2 |EPD 7.2-2 (32-bit)| (default, Sep 14 2011, 11:02:05) [MSC v.1500 32 bit (Intel)] Type "copyright", "credits" or "license" for more information. IPython 0.12 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: In [2]: print "%d + %d = %d" % (2, 3, 2+3) 2**5 2 + 3 = 5 In [3]: Out[3]: 32 In [4]: In [4]: In [4]: 'org_babel_python_eoe' In [4]: Out[4]: 'org_babel_python_eoe' In [5]:
Re: [O] URGENT Bug with exporting org source block
Eric Schulte writes: >> With your latest changes I get this test regression (I have not checked >> which commit is responsible): >> > > This is odd. The first time I ran the test suite this test failed for > me as well, however on all subsequent runs of the test suite this test > passed, and manually looking through the test the code indeed does seem > to be acting as it should. This, together with the fact that I'll always start the test from a fresh 'emacs -Q' would hint at some variable that needs declaration or some other newly introduced dependency. Do you have an idea what to look for? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] org-mime-htmlize: visual representation (thunderbird)
Eric Schulte wrote: > >> However thunderbird does not and I apply the resulting eml >> file below (I presume a screenshot is not appropriated) >> > > This sounds like a thunderbird bug -- not properly displaying multi-part > messages. Hm I will try to send them a bug report then > >> >> Now tunderbird itself has an extension (latex-it) which does >> something similar to org-mime-htmlize, it sends latex math >> as png. However there are "better* displayed, I attach the >> relevant eml file below. >> > > The difference between org-mime-htmlize and latex-it is that the former > converts each formulas to its own png image, while the later converts > the entire message to one large pdf file which is then attached as a > single image. yes and no: latexit can do what you describe (and the author admits that it only makes sense for documents whose size does not exceed one page. latexit can also embed in html pages latex formulas, however only $$ are allowed no equations (which makes it inferior to org-preview-latex-fragments) In any case I attached the wrong eml file (the one with just one page) I now attach the eml with the embedded formula. Maybe some useful information can be extracted. Uwe Brauer --- Begin Message --- Integral And --- End Message ---
[O] Regression in `org-todo'
Commit 6cbf1f417222321a47848a7368427ba8a22fe3a5 renames variable `last-state' to `org-last-state' in org.el. This change isn't reflected in function `org-todo'. That causes the following regression: Toggling a TODO state to DONE on a headline via C-c C-t (`org-todo') results in: "Symbol's value as variable is void: org-last-state". This is reproducible in latest HEAD and even in tag 'release_7.8.07'. M-x emacs-version: GNU Emacs 24.0.94.1 (i386-apple-darwin11.3.0, NS apple-appkit-1138.32) of 2012-03-12 on moritz-macbook.local The attached patch contains a simple (two line) fix. Cheers, Moritz Ulrich -- Moritz Ulrich fix-org-last-state.patch Description: Binary data
Re: [O] Python code block hangs with :session if python-mode is loaded
Richard Stanton writes: > I have python-mode (latest version from Launchpad) set up to handle python > editing in Emacs. > > Using orgmode, the following code block runs fine if Ipress C-c C-c, > producing the (correct) output shown: > > #+begin_src python :results output > print "%d + %d = %d" % (2, 3, 2+3) > 2**5 > #+end_src > > #+RESULTS: > : 2 + 3 = 5 > > If I do not have (require 'python-mode) in my init.el, the following also > works fine: > > #+begin_src python :results output :session > print "%d + %d = %d" % (2, 3, 2+3) > 2**5 > #+end_src > > #+RESULTS: > : 2 + 3 = 5 > : 32 > > However, if (require 'python-mode) is in my init.el file, pressing C-c > C-c in the second code block causes Emacs to hang with the message > "Executing python code block". I can get out by pressing C-g, but it > never returns otherwise. > Hi Richard, The above executes without problem for me regardless of whether python-mode has been explicitly loaded. I have python mode py-version "5.1.0" on my machine. My guess is that python-mode changed the session prompt in such a way that Babel can not tell when execution has completed. I have the following in my *Python* session buffer after execution [1], what are the contents of your *Python* session buffer after you have C-g'd out of the loop? Best, Footnotes: [1] *Python* >>> print "%d + %d = %d" % (2, 3, 2+3) 2 + 3 = 5 2**5 >>> 32 >>> >>> >>> 'org_babel_python_eoe' >>> 'org_babel_python_eoe' >>> print "%d + %d = %d" % (2, 3, 2+3) 2 + 3 = 5 >>> 2**5 32 >>> >>> >>> >>> 'org_babel_python_eoe' 'org_babel_python_eoe' >>> -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] URGENT Bug with exporting org source block
Achim Gratz writes:
> Eric Schulte writes:
> [...]
>
> With your latest changes I get this test regression (I have not checked
> which commit is responsible):
>
This is odd. The first time I ran the test suite this test failed for
me as well, however on all subsequent runs of the test suite this test
passed, and manually looking through the test the code indeed does seem
to be acting as it should.
Best,
>
> Test ob-exp/noweb-on-export-with-exports-results backtrace:
> <(357 nil)
> apply(< (357 nil))
> (setq value-605 (apply fn-603 args-604))
> (unwind-protect (setq value-605 (apply fn-603 args-604)) (setq form-
> (if (unwind-protect (setq value-605 (apply fn-603 args-604)) (setq f
> (unless (unwind-protect (setq value-605 (apply fn-603 args-604)) (se
> (let (form-description-607) (unless (unwind-protect (setq value-605
> (let ((value-605 (quote ert-form-evaluation-aborted-606))) (let (for
> (let ((fn-603 (function <)) (args-604 (list test-point (re-search-fo
> (should (< test-point (re-search-forward x nil t)))
> (lambda (x) (should (< test-point (re-search-forward x nil t))) (set
> mapcar((lambda (x) (should (< test-point (re-search-forward x nil t)
> (setq G93507 (mapcar (lambda (x) (should (< test-point (re-search-fo
> (let ((kill-buffer-query-functions nil) G93507) (with-temp-file "/tm
> (org-test-with-temp-text-in-file exported-html (mapcar (lambda (x) (
> (let ((exported-html (org-export-as-html nil nil nil (quote string)
> (save-restriction (org-narrow-to-subtree) (let ((exported-html (org-
> (progn (org-id-goto "8701beb4-13d9-468c-997a-8e63e8b66f8d") (setq to
> (unwind-protect (progn (org-id-goto "8701beb4-13d9-468c-997a-8e63e8b
> (let ((save-match-data-internal (match-data))) (unwind-protect (prog
> (save-match-data (org-id-goto "8701beb4-13d9-468c-997a-8e63e8b66f8d"
> (progn (save-match-data (org-id-goto "8701beb4-13d9-468c-997a-8e63e8
> (unwind-protect (progn (save-match-data (org-id-goto "8701beb4-13d9-
> (let ((wconfig (current-window-configuration))) (unwind-protect (pro
> (save-window-excursion (save-match-data (org-id-goto "8701beb4-13d9-
> (let* ((id-location (org-id-find "8701beb4-13d9-468c-997a-8e63e8b66f
> (org-test-at-id "8701beb4-13d9-468c-997a-8e63e8b66f8d" (org-narrow-t
> (lambda nil (org-test-at-id "8701beb4-13d9-468c-997a-8e63e8b66f8d" (
> byte-code("\306\307!▒q\210\310\216\311 \312\216\313\314\315\316\3
> ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
> byte-code("\306\307!\211▒r\310\311!q\210\312 d\313\223)L\210\314\216
> ert-run-test([cl-struct-ert-test ob-exp/noweb-on-export-with-exports
> ert-run-or-rerun-test([cl-struct-ert--stats "\\(org\\|ob\\)" [[cl-st
> ert-run-tests("\\(org\\|ob\\)" #[(event-type &rest event-args) \30
> ert-run-tests-batch("\\(org\\|ob\\)")
> ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
> (let ((org-id-track-globally t) (org-id-locations-file (convert-stan
> org-test-run-batch-tests()
> call-interactively(org-test-run-batch-tests nil nil)
> command-execute(org-test-run-batch-tests)
> command-line-1(("-L" "lisp/" "-L" "testing/" "--eval" "(defconst org
> command-line()
> normal-top-level()
> Test ob-exp/noweb-on-export-with-exports-results condition:
> (wrong-type-argument number-or-marker-p nil)
>FAILED 21/193 ob-exp/noweb-on-export-with-exports-results
>
>
> Regards,
> Achim.
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [PATCH] link descriptions in :file results of src blocks
Andreas Leha writes: > Eric Schulte writes: > >> [...] I would like to apply this patch, however I have some questions about the use of the :file argument and the result itself to fill in the description if the :filelinkdescr header argument is left blank. Also, I would suggest that :file-desc is a better name for this header argument. >>> >>> Hi Eric, >>> >>> thanks for considering this patch. Feel free to change the term to >>> anything more appropriate. >>> In my opinion using the :file argument as a description changes (or at least adds to) the meaning of the :file header argument. Is there a significant benefit to this behavior? If not I'd prefer that an empty :file-desc header argument have no effect. >>> >>> My original use case was indeed making a code block to >>> produce [[file.pdf][file.pdf]] instead of [[file.pdf]] (see >>> http://permalink.gmane.org/gmane.emacs.orgmode/53941). So, if you >>> remove the possibility to specify an empty :file-desc, for me that would >>> mean to give the file name twice, as in >>> : #+begin_src R :results graphics :file test2.png :file-desc test2.png >>> which would be avoidable with my proposed behaviour. >>> >>> I could live with that, though I'd still prefer not to have to type more >>> than necessary... >>> >> >> Makes sense, I've just pushed up a solution which builds on your initial >> patch by >> >> 1. changing :filelinkdescr to :file-desc >> >> 2. when an empty :file-desc header argument is specified it's value is >>set to the value of the file path resulting in >>[[file.pdf][file.pdf]] >> >> 3. adding documentation and a test case >> >> Please let me know if this misses any part of your intended use case. >> >> Thanks for the contribution! > > Hi Eric, > > I seem not to be able to see that push. My git log contains only > , > | 8d43aa2 test the new file-desc header argument > | 670c7f3 simplified implementation of :file-desc header argument > | 1193844 documentation for the new file-desc header argument > | 59800b2 change name of filelinkdescr to file-desc > | a58a4f0 new source block header argument :filelinkdescr > ` > and indeed, the functionality you describe in 2. seems not to be > available. What did I miss? > Hi Andreas, The commit implementing the behavior described in (2) is 670c7f3. Please take a look at the test-ob/file-desc-header-argument test case. If it is passing on your system (as it is on mine) then the behavior described in (2) is in fact implemented. Best, > > Regards, > Andreas > > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Org release 7.8.07 (BUGFIX-only release)
Bastien writes: >> In org-find-library-name: >> org-compat.el:341:14:Warning: find-library called with 3 arguments, but >> accepts only 1 > > Well, this is the culprit compatibility defun: > > (defun org-find-library-name (library) > (if (fboundp 'find-library-name) > (file-name-directory (find-library-name library)) > ; XEmacs does not have `find-library-name' > (flet ((find-library-name-helper (filename ignored-codesys) >filename) > (find-library-name (library) > (find-library library nil 'find-library-name-helper))) < > (file-name-directory (find-library-name library) > > I don't know how to circumvent this warning and btw I don't have this > warning in Emacs 24.0.94.1. I also do not have this warning when compiling org-compat.el in isolation, but I do have this warning when I do a batch-byte-recompile-directory. That is never a good sign... Anyway, I think that most if not all these defuns in org-compat.el should really be macros (although careful quoting has to be applied) so that the byte-compiler only needs to compile whatever is appropriate. (defmacro org-find-library-name (library) (if (fboundp 'find-library-name) `(file-name-directory (find-library-name ,library)) ; XEmacs does not have `find-library-name' `(flet ((find-library-name-helper (filename ignored-codesys) filename) (find-library-name (library) (find-library library nil 'find-library-name-helper))) (file-name-directory (find-library-name ,library) I also don't think an flet macro should be used here (or it should also be expanded at compile time, which I can't see how to do easily), maybe replace with a lambda expression? Looking at the definition of find-library in XEmacs makes me a bit queasy, but I think it needs three arguments to tell it not to display the file in a window... (defmacro org-find-library-name (library) (if (fboundp 'find-library-name) `(file-name-directory (find-library-name ,library)) ; XEmacs does not have `find-library-name' `(file-name-directory (find-library ,library nil (lambda (lib ignore) lib) Anyway, something to do after Emacs 24.1 is out. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
[O] org-crypt won't work with new version of gpg
I'm running arch linux and emacs/org versions below. I had this problem once before when the gpg package for arch was updated and I had to repair a symlink in the /usr/bin directory, I think, but now I can't figure out what's going on. GPG was updated a few days ago, and now when I go to unencrypt anything I get: epg--check-error-for-decrypt: peculiar error: "Decryption failed", "" Which is unhelpful. The 'gpg' command on the command line works fine -- it is symlinked to 'gpg2', which is the real executable. I thought that when something went wrong earlier it had to do with this symlink being deleted, but it's there, and still… I've got `org-crypt-key' set to my private key, and other than that no real customizations. Any hints very welcome! Thanks, Eric -- GNU Emacs 24.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-03-06 on pellet Org-mode version 7.8.06 (release_7.8.07.123.ge917)
Re: [O] Please test: Fix global variables names
Bastien writes: > Here is a patch against hotfix to fix warnings about wrong > variables names (with Emacs 24). > > Please test it heavily. > > Thanks a lot to Martyn Jago for a preliminary set of patches > for this! This is now part of 7.8.07. -- Bastien
Re: [O] Org release 7.8.07 (BUGFIX-only release)
Hi all, Bastien writes: > I have just released Org 7.8.07 -- a BUGFIX-only release. > > This is the version that will be merged into Emacs' trunk > by tomorrow. Please report critical bugs using "URGENT" > in the subject line. Org 7.8.07 (commit da0e6f) is now part of Emacs trunk. Best, -- Bastien
Re: [O] [DEV] New git workflow
Hi Nick, I did not mean to imply git is not capable of working that way. It's more a question of what is accepted practice and most importantly, what fits the problem you actually have. The difference between both approaches, it seems to me, shows when there is a difference between the fix is it would have looked when done right from the first day on, and the fix as it looks when introduced later. Daggy fixes' mental image is to incrementally fix your release branches (or how you call them) each the in way it needs to be fixed. Cherry-picking usually implies (but does not mandate!) fix on master, then go back. Git's support for the other way round could be better, e.g. by introducing a DAGGY_FIX_HEAD and repo mode so you don't need to alternate cherry-pick, tag, checkout, ... To me the mental image behind is the main difference, and what is better depends on the fix and the project and what not. Just my 2c. Cheers, Simon On 03/24/2012 08:29 PM, Nick Dokos wrote: Simon Thum wrote: Hi Daniel, On 03/24/2012 12:05 PM, Daniel Dehennin wrote: Simon Thum writes: It seems that one problem with cherry-picking is the tracking of what is in which branch and from where it comes. I'm not a git neither DVCS guru, but daggyfixes[1][2][3] is saner than cherry-picking. I'm a bit biased as I mainly have git experience but to me it seems that both cherry-picking and daggy fixes have their strengths and weaknesses, and I'd rather have them both in all the VCSes but needless fights over which one is ultimately superior. Git should probably learn that thing, IMO. I'm probably missing something but what's there to learn? You check out the offending commit, make a branch off of it, commit the fix on the branch, give it a tag (so you can find it easily later on) and then merge it back anywhere you want. AFAICT, that's all there is to daggy-fixes and git is perfectly capable of doing that - no? Nick Footnotes: [1] http://mercurial.selenic.com/wiki/DaggyFixes [2] http://wiki.monotone.ca/DaggyFixes/ [3] http://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from
Re: [O] Org release 7.8.07 (BUGFIX-only release)
Hi Eric, Eric Schulte writes: >> I've pushed two bug fixes up to the hotfix-7.8.06 branch this morning. >^ > three >> >> These should both be included in the code merged with Emacs. I've >> marked the emails related to these bugs as URGENT. Noted, thanks. I will merge Org>Emacs from the hotfix branch. But let's keep this branch very "hot" (only critical bugfixes.) Thanks! -- Bastien
Re: [O] Org release 7.8.07 (BUGFIX-only release)
Hi Achim, Achim Gratz writes: > Bastien writes: >> This is the version that will be merged into Emacs' trunk >> by tomorrow. > > Please tag the release on maint so that Git reports the correct > version. Done. (I tagged locally but forgot to push the tag.) >> Please report critical bugs using "URGENT" >> in the subject line. > > All tests (except for R which I can't run due to lack of ESS) are clean > on openSUSE/Tumbleweed with both Emacs 23.4 and 24.0.94. Yes. >> Thanks all for your help! > > I'm still getting these complaints about unprefixed / global variables > w/ latest Emacs24 from trunk and fresh pull from master: > > In toplevel form: > org.el:4871:1:Warning: global/dynamic var `date' lacks a prefix > > In toplevel form: > org-agenda.el:95:1:Warning: global/dynamic var `date' lacks a prefix > > In toplevel form: > org-bbdb.el:122:1:Warning: global/dynamic var `date' lacks a prefix > org-bbdb.el:123:1:Warning: global/dynamic var `name' lacks a prefix The problem with the `name' global variable is not in maint, I will have a look in master. > In toplevel form: > org-remember.el:280:1:Warning: global/dynamic var `annotation' lacks a prefix > org-remember.el:281:1:Warning: global/dynamic var `initial' lacks a prefix Yes, I know. This is not easy to fix, because the ̀date' global variable is set from calendar. Same for annotation and initial, which are set from remember.el. If you see a place where the fix is trivial (i.e. where my assumption is false), please submit it. > There is something going on in org-compat that I don't understand at all > (note that find-library is not called at that poit at all, so there must > be some macro expansion at work). This is also in Emacs23: > > In org-find-library-name: > org-compat.el:341:14:Warning: find-library called with 3 arguments, but > accepts only 1 Well, this is the culprit compatibility defun: (defun org-find-library-name (library) (if (fboundp 'find-library-name) (file-name-directory (find-library-name library)) ; XEmacs does not have `find-library-name' (flet ((find-library-name-helper (filename ignored-codesys) filename) (find-library-name (library) (find-library library nil 'find-library-name-helper))) < (file-name-directory (find-library-name library) I don't know how to circumvent this warning and btw I don't have this warning in Emacs 24.0.94.1. > Lastly, there's a function that has been obsoleted with Emacs24, so it > should probably get a shim in org-compat to refer to one or the other > definition based on Emacs version in a with-no-error form. > > In org-indent-mode: > org-indent.el:212:11:Warning: `buffer-substring-filters' is an obsolete > variable (as of 24.1); use `filter-buffer-substring-functions' instead. > org-indent.el:213:12:Warning: `buffer-substring-filters' is an obsolete > variable (as of 24.1); use `filter-buffer-substring-functions' instead. > org-indent.el:213:12:Warning: `buffer-substring-filters' is an obsolete > variable (as of 24.1); use `filter-buffer-substring-functions' instead. Yes. The fix is not trivial. Patch welcome! Thanks, -- Bastien
Re: [O] [PATCH] Support hour in repeated task cookie
Hi Takafumi, Takafumi Arakaki writes: > No comments? No one wants to have "+3h" in SCHEDULED? please be patient. Developers are working on their free time. Also, please refine the ChangeLog of your patch by adding an Emacs changelog entry with `C-x 4 a'. Because the patch is not trivial. This is documented in http://orgmode.org/worg/org-contribute.html Thanks, -- Bastien
Re: [O] [PATCH] link descriptions in :file results of src blocks
Eric Schulte writes: > [...] >>> I would like to apply this patch, however I have some questions about >>> the use of the :file argument and the result itself to fill in the >>> description if the :filelinkdescr header argument is left blank. Also, >>> I would suggest that :file-desc is a better name for this header >>> argument. >> >> Hi Eric, >> >> thanks for considering this patch. Feel free to change the term to >> anything more appropriate. >> >>> >>> In my opinion using the :file argument as a description changes (or at >>> least adds to) the meaning of the :file header argument. Is there a >>> significant benefit to this behavior? If not I'd prefer that an empty >>> :file-desc header argument have no effect. >> >> My original use case was indeed making a code block to >> produce [[file.pdf][file.pdf]] instead of [[file.pdf]] (see >> http://permalink.gmane.org/gmane.emacs.orgmode/53941). So, if you >> remove the possibility to specify an empty :file-desc, for me that would >> mean to give the file name twice, as in >> : #+begin_src R :results graphics :file test2.png :file-desc test2.png >> which would be avoidable with my proposed behaviour. >> >> I could live with that, though I'd still prefer not to have to type more >> than necessary... >> > > Makes sense, I've just pushed up a solution which builds on your initial > patch by > > 1. changing :filelinkdescr to :file-desc > > 2. when an empty :file-desc header argument is specified it's value is >set to the value of the file path resulting in >[[file.pdf][file.pdf]] > > 3. adding documentation and a test case > > Please let me know if this misses any part of your intended use case. > > Thanks for the contribution! Hi Eric, I seem not to be able to see that push. My git log contains only , | 8d43aa2 test the new file-desc header argument | 670c7f3 simplified implementation of :file-desc header argument | 1193844 documentation for the new file-desc header argument | 59800b2 change name of filelinkdescr to file-desc | a58a4f0 new source block header argument :filelinkdescr ` and indeed, the functionality you describe in 2. seems not to be available. What did I miss? Regards, Andreas
Re: [O] URGENT Bug with exporting org source block
Eric Schulte writes:
[...]
With your latest changes I get this test regression (I have not checked
which commit is responsible):
Test ob-exp/noweb-on-export-with-exports-results backtrace:
<(357 nil)
apply(< (357 nil))
(setq value-605 (apply fn-603 args-604))
(unwind-protect (setq value-605 (apply fn-603 args-604)) (setq form-
(if (unwind-protect (setq value-605 (apply fn-603 args-604)) (setq f
(unless (unwind-protect (setq value-605 (apply fn-603 args-604)) (se
(let (form-description-607) (unless (unwind-protect (setq value-605
(let ((value-605 (quote ert-form-evaluation-aborted-606))) (let (for
(let ((fn-603 (function <)) (args-604 (list test-point (re-search-fo
(should (< test-point (re-search-forward x nil t)))
(lambda (x) (should (< test-point (re-search-forward x nil t))) (set
mapcar((lambda (x) (should (< test-point (re-search-forward x nil t)
(setq G93507 (mapcar (lambda (x) (should (< test-point (re-search-fo
(let ((kill-buffer-query-functions nil) G93507) (with-temp-file "/tm
(org-test-with-temp-text-in-file exported-html (mapcar (lambda (x) (
(let ((exported-html (org-export-as-html nil nil nil (quote string)
(save-restriction (org-narrow-to-subtree) (let ((exported-html (org-
(progn (org-id-goto "8701beb4-13d9-468c-997a-8e63e8b66f8d") (setq to
(unwind-protect (progn (org-id-goto "8701beb4-13d9-468c-997a-8e63e8b
(let ((save-match-data-internal (match-data))) (unwind-protect (prog
(save-match-data (org-id-goto "8701beb4-13d9-468c-997a-8e63e8b66f8d"
(progn (save-match-data (org-id-goto "8701beb4-13d9-468c-997a-8e63e8
(unwind-protect (progn (save-match-data (org-id-goto "8701beb4-13d9-
(let ((wconfig (current-window-configuration))) (unwind-protect (pro
(save-window-excursion (save-match-data (org-id-goto "8701beb4-13d9-
(let* ((id-location (org-id-find "8701beb4-13d9-468c-997a-8e63e8b66f
(org-test-at-id "8701beb4-13d9-468c-997a-8e63e8b66f8d" (org-narrow-t
(lambda nil (org-test-at-id "8701beb4-13d9-468c-997a-8e63e8b66f8d" (
byte-code("\306\307!▒q\210\310\216\311 \312\216\313\314\315\316\3
ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
byte-code("\306\307!\211▒r\310\311!q\210\312 d\313\223)L\210\314\216
ert-run-test([cl-struct-ert-test ob-exp/noweb-on-export-with-exports
ert-run-or-rerun-test([cl-struct-ert--stats "\\(org\\|ob\\)" [[cl-st
ert-run-tests("\\(org\\|ob\\)" #[(event-type &rest event-args) \30
ert-run-tests-batch("\\(org\\|ob\\)")
ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
(let ((org-id-track-globally t) (org-id-locations-file (convert-stan
org-test-run-batch-tests()
call-interactively(org-test-run-batch-tests nil nil)
command-execute(org-test-run-batch-tests)
command-line-1(("-L" "lisp/" "-L" "testing/" "--eval" "(defconst org
command-line()
normal-top-level()
Test ob-exp/noweb-on-export-with-exports-results condition:
(wrong-type-argument number-or-marker-p nil)
FAILED 21/193 ob-exp/noweb-on-export-with-exports-results
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
