* Macro question with new texinfo exporter
@ 2013-01-28 20:19 Thomas S. Dye
2013-01-29 18:21 ` Nicolas Goaziou
0 siblings, 1 reply; 35+ messages in thread
From: Thomas S. Dye @ 2013-01-28 20:19 UTC (permalink / raw)
To: Org-mode
Aloha all,
I have the following two macros:
#+MACRO: markup @@info:@$1{@@$2@@info:}@@
#+MACRO: kbd {{{markup(kbd,$1)}}}
When I export to texinfo using the new exporter, the following macro
call triggers an error (byte-code: Wrong type argument: consp, nil):
{{{kbd(C-,)}}}
and so does this:
{{{kbd(C-\,)}}}
In fact, any number of backslashes appears to trigger the same error.
I'm hoping to find @kbd{C-,} in the .texi output.
All the best,
Tom
--
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: Macro question with new texinfo exporter 2013-01-28 20:19 Macro question with new texinfo exporter Thomas S. Dye @ 2013-01-29 18:21 ` Nicolas Goaziou 2013-01-29 18:49 ` Thomas S. Dye 2013-01-30 9:22 ` Bastien 0 siblings, 2 replies; 35+ messages in thread From: Nicolas Goaziou @ 2013-01-29 18:21 UTC (permalink / raw) To: Thomas S. Dye; +Cc: Org-mode Hello, tsd@tsdye.com (Thomas S. Dye) writes: > I have the following two macros: > > #+MACRO: markup @@info:@$1{@@$2@@info:}@@ > #+MACRO: kbd {{{markup(kbd,$1)}}} > > When I export to texinfo using the new exporter, the following macro > call triggers an error (byte-code: Wrong type argument: consp, nil): > > {{{kbd(C-,)}}} > > and so does this: > > {{{kbd(C-\,)}}} > > In fact, any number of backslashes appears to trigger the same error. > > I'm hoping to find @kbd{C-,} in the .texi output. I didn't try it, but it probably comes from the syntax of macros, which is a bit brittle wrt commas. We ought to modify it. Perhaps something like: {{{name arg1 "arg2 with space" "arg3 \"with\" quote"}}} Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-29 18:21 ` Nicolas Goaziou @ 2013-01-29 18:49 ` Thomas S. Dye 2013-01-30 9:22 ` Bastien 1 sibling, 0 replies; 35+ messages in thread From: Thomas S. Dye @ 2013-01-29 18:49 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org-mode Nicolas Goaziou <n.goaziou@gmail.com> writes: > > I didn't try it, but it probably comes from the syntax of macros, which > is a bit brittle wrt commas. > > We ought to modify it. Perhaps something like: > > {{{name arg1 "arg2 with space" "arg3 \"with\" quote"}}} So, with the modification, I'd write {{{kbd("C-,")}}}? That would be easy on my end. All the best, Tom -- Thomas S. Dye http://www.tsdye.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-29 18:21 ` Nicolas Goaziou 2013-01-29 18:49 ` Thomas S. Dye @ 2013-01-30 9:22 ` Bastien 2013-01-30 12:44 ` Nicolas Goaziou 1 sibling, 1 reply; 35+ messages in thread From: Bastien @ 2013-01-30 9:22 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org-mode, Thomas S. Dye Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > We ought to modify it. Perhaps something like: > > {{{name arg1 "arg2 with space" "arg3 \"with\" quote"}}} FWIW I'm all for a variation of this {{{name(arg1 "arg2 with space" "arg3 \"with\" quote")}}} if we can also support the old syntax. The reason why I prefer the parentheses is that it makes clear for newbies that the items within the parentheses are arguments, whereas I find it less clear with no parentheses. -- Bastien ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-30 9:22 ` Bastien @ 2013-01-30 12:44 ` Nicolas Goaziou 2013-01-30 16:14 ` Bastien 0 siblings, 1 reply; 35+ messages in thread From: Nicolas Goaziou @ 2013-01-30 12:44 UTC (permalink / raw) To: Bastien; +Cc: Org-mode, Thomas S. Dye Hello, Bastien <bzg@altern.org> writes: > FWIW I'm all for a variation of this > > {{{name(arg1 "arg2 with space" "arg3 \"with\" quote")}}} > > if we can also support the old syntax. Supporting old syntax is a bit tricky. Perhaps something like: - Find the first one to appear between comma and quote: - if it is a comma, use old syntax - in any other case, use new syntax. > The reason why I prefer the parentheses is that it makes > clear for newbies that the items within the parentheses > are arguments, whereas I find it less clear with no > parentheses. Write more Lisp ;) Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-30 12:44 ` Nicolas Goaziou @ 2013-01-30 16:14 ` Bastien 2013-01-30 22:24 ` Nicolas Goaziou 0 siblings, 1 reply; 35+ messages in thread From: Bastien @ 2013-01-30 16:14 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org-mode, Thomas S. Dye Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > Supporting old syntax is a bit tricky. Perhaps something like: > > - Find the first one to appear between comma and quote: > - if it is a comma, use old syntax > - in any other case, use new syntax. Sounds good to me. >> The reason why I prefer the parentheses is that it makes >> clear for newbies that the items within the parentheses >> are arguments, whereas I find it less clear with no >> parentheses. > > Write more Lisp ;) (You mean... I should (perhaps) write less lisp (right)?) -- Bastien ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-30 16:14 ` Bastien @ 2013-01-30 22:24 ` Nicolas Goaziou 2013-01-31 2:21 ` Thomas S. Dye 2013-01-31 13:51 ` Bastien 0 siblings, 2 replies; 35+ messages in thread From: Nicolas Goaziou @ 2013-01-30 22:24 UTC (permalink / raw) To: Bastien; +Cc: Org-mode, Thomas S. Dye Bastien <bzg@altern.org> writes: > Nicolas Goaziou <n.goaziou@gmail.com> writes: > >> Supporting old syntax is a bit tricky. Perhaps something like: >> >> - Find the first one to appear between comma and quote: >> - if it is a comma, use old syntax >> - in any other case, use new syntax. > > Sounds good to me. OTOH, the change will happen during a major release. Moreover macros belong to an export framework which have been totally rewritten. Must we cope with backward compatibility in this case ? Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-30 22:24 ` Nicolas Goaziou @ 2013-01-31 2:21 ` Thomas S. Dye 2013-01-31 13:51 ` Bastien 1 sibling, 0 replies; 35+ messages in thread From: Thomas S. Dye @ 2013-01-31 2:21 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Bastien, Org-mode Nicolas Goaziou <n.goaziou@gmail.com> writes: > Bastien <bzg@altern.org> writes: > >> Nicolas Goaziou <n.goaziou@gmail.com> writes: >> >>> Supporting old syntax is a bit tricky. Perhaps something like: >>> >>> - Find the first one to appear between comma and quote: >>> - if it is a comma, use old syntax >>> - in any other case, use new syntax. >> >> Sounds good to me. > > OTOH, the change will happen during a major release. Moreover macros > belong to an export framework which have been totally rewritten. Must we > cope with backward compatibility in this case ? Perhaps make macro expansion conditional on old/new exporter, rather than the form of the macro? Tom -- Thomas S. Dye http://www.tsdye.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-30 22:24 ` Nicolas Goaziou 2013-01-31 2:21 ` Thomas S. Dye @ 2013-01-31 13:51 ` Bastien 2013-01-31 13:58 ` Nicolas Goaziou 2013-01-31 21:23 ` Nicolas Goaziou 1 sibling, 2 replies; 35+ messages in thread From: Bastien @ 2013-01-31 13:51 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org-mode, Thomas S. Dye Hi Nicolas, Nicolas Goaziou <n.goaziou@gmail.com> writes: > OTOH, the change will happen during a major release. Moreover macros > belong to an export framework which have been totally rewritten. Must we > cope with backward compatibility in this case ? I'd say "as much as we can", yes. But if an incompatible change must appear, 8.0 is a good timing, I agree. Now back to the issue at hand, what about simply allowing to escape the , and " characters? This was Thomas first try, and a natural one I'd say. What do you think? -- Bastien ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-31 13:51 ` Bastien @ 2013-01-31 13:58 ` Nicolas Goaziou 2013-01-31 21:23 ` Nicolas Goaziou 1 sibling, 0 replies; 35+ messages in thread From: Nicolas Goaziou @ 2013-01-31 13:58 UTC (permalink / raw) To: Bastien; +Cc: Org-mode, Thomas S. Dye Bastien <bzg@altern.org> writes: > Now back to the issue at hand, what about simply allowing to escape > the , and " characters? This was Thomas first try, and a natural one > I'd say. > > What do you think? In this case, there's no point in allowing to escape quotation marks. The current syntax handles them fine. However, it should be possible to escape backslashes, as "\\," is different from "\,". I'll have a look at it a bit later. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-31 13:51 ` Bastien 2013-01-31 13:58 ` Nicolas Goaziou @ 2013-01-31 21:23 ` Nicolas Goaziou 2013-02-04 15:43 ` Thomas S. Dye 1 sibling, 1 reply; 35+ messages in thread From: Nicolas Goaziou @ 2013-01-31 21:23 UTC (permalink / raw) To: Bastien; +Cc: Org-mode, Thomas S. Dye Bastien <bzg@altern.org> writes: > Now back to the issue at hand, what about simply allowing to escape > the , and " characters? This was Thomas first try, and a natural one > I'd say. I have pushed a fix in maint for that. It should now be possible to use {{{kbd(C-\,)}}} to get "C-," as argument. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-01-31 21:23 ` Nicolas Goaziou @ 2013-02-04 15:43 ` Thomas S. Dye 2013-02-04 17:26 ` Bastien ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Thomas S. Dye @ 2013-02-04 15:43 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Bastien, Org-mode Nicolas Goaziou <n.goaziou@gmail.com> writes: > Bastien <bzg@altern.org> writes: > >> Now back to the issue at hand, what about simply allowing to escape >> the , and " characters? This was Thomas first try, and a natural one >> I'd say. > > I have pushed a fix in maint for that. It should now be possible to use > {{{kbd(C-\,)}}} to get "C-," as argument. I need a bit more help with this. I created a tracking branch for maint: git branch --track maint origin/maint Then, I checkout maint: git checkout maint Reloading Org yields these messages: The following features were found in load-path, please check if that's correct: (org-e-texinfo org-export) Some error occured while reloading Org features (ob-core ob-tcl) Please check *Messages*! Org-mode version 7.9.3e (7.9.3e @ /Users/dk/.emacs.d/src/org-mode/lisp/) cond: Symbol's function definition is void: org-e-latex-export-to-latex I'm stymied here. I'd like to be able to use the new macro code with the new exporter. How is that possible? All the best, Tom -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-04 15:43 ` Thomas S. Dye @ 2013-02-04 17:26 ` Bastien 2013-02-04 18:57 ` Achim Gratz 2013-02-04 18:10 ` Nicolas Goaziou 2013-02-04 18:38 ` Achim Gratz 2 siblings, 1 reply; 35+ messages in thread From: Bastien @ 2013-02-04 17:26 UTC (permalink / raw) To: Thomas S. Dye; +Cc: Org-mode, Nicolas Goaziou Hi Thomas, tsd@tsdye.com (Thomas S. Dye) writes: > I'm stymied here. I'd like to be able to use the new macro code with > the new exporter. How is that possible? You need to reload uncompiled files with C-u M-x org-reload RET BTW, I think it should be the defaut behavior of org-reload. Achim, any objection of making it the default, while C-u M-x org-reload RET would reload compiled files if any? -- Bastien ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-04 17:26 ` Bastien @ 2013-02-04 18:57 ` Achim Gratz 2013-02-16 9:21 ` Bastien 0 siblings, 1 reply; 35+ messages in thread From: Achim Gratz @ 2013-02-04 18:57 UTC (permalink / raw) To: emacs-orgmode Bastien writes: > You need to reload uncompiled files with C-u M-x org-reload RET I don't see the relation to the original problem, which is caused by a switch from master to maint. This will not work without at least unloading Org or better, restarting Emacs. > BTW, I think it should be the defaut behavior of org-reload. > > Achim, any objection of making it the default, while > C-u M-x org-reload RET would reload compiled files if any? I think that the current default, which has been in place for years, is just fine. Reloading uncompiled is only useful for when you want to create backtraces. If you always want to run uncompiled, then you can opt to never compile Org and org-reload will follow suit, if you clean up load-path to not contain older (compiled) Org distributions: --8<---------------cut here---------------start------------->8--- (setq load-path (delq nil (mapcar (lambda (p) (when (not (string-match "lisp/org$" p)) p)) load-path))) (add-to-list 'load-path "/path/to/uncompiled/org") (load "org-loaddefs.el" nil nil 'nosuffix) --8<---------------cut here---------------end--------------->8--- Of course you should not do this after Org has already been loaded. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-04 18:57 ` Achim Gratz @ 2013-02-16 9:21 ` Bastien 2013-02-16 10:19 ` Achim Gratz 0 siblings, 1 reply; 35+ messages in thread From: Bastien @ 2013-02-16 9:21 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Hi Achim, Achim Gratz <Stromeko@nexgo.de> writes: > I don't see the relation to the original problem, which is caused by a > switch from master to maint. Yes, I realized this. > I think that the current default, which has been in place for years, is > just fine. Fair enough. > Reloading uncompiled is only useful for when you want to > create backtraces. ... which is why I always want, but users don't, I agree. Thanks, -- Bastien ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-16 9:21 ` Bastien @ 2013-02-16 10:19 ` Achim Gratz 2013-02-16 10:34 ` Bastien 0 siblings, 1 reply; 35+ messages in thread From: Achim Gratz @ 2013-02-16 10:19 UTC (permalink / raw) To: emacs-orgmode Bastien writes: >> Reloading uncompiled is only useful for when you want to >> create backtraces. > > ... which is why I always want, but users don't, I agree. We could provide org-reload-uncompiled that calls org-reload with a prefix argument, which would allow anyone so inclined to map "C-c C-x !" to org-reload-uncompiled or another binding could be found. BTW, I just see that the menu entry for loading org uncompiled is wrong, it still tries to run it via "C-u C-c C-x r", which isn't bound anymore since Org 6.26d due to a conflict with bindings in other modes. Looks like nobody ever used this in the last four years… fixed in maint and merged to master. 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-16 10:19 ` Achim Gratz @ 2013-02-16 10:34 ` Bastien 2013-02-16 10:39 ` Achim Gratz 2013-02-16 16:19 ` Nick Dokos 0 siblings, 2 replies; 35+ messages in thread From: Bastien @ 2013-02-16 10:34 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Achim Gratz <Stromeko@nexgo.de> writes: > Bastien writes: >>> Reloading uncompiled is only useful for when you want to >>> create backtraces. >> >> ... which is why I always want, but users don't, I agree. > > We could provide org-reload-uncompiled that calls org-reload with a > prefix argument, which would allow anyone so inclined to map "C-c C-x !" > to org-reload-uncompiled or another binding could be found. I don't think this is necessary, C-u C-c C-x ! is easy enough. > BTW, I just see that the menu entry for loading org uncompiled is wrong, > it still tries to run it via "C-u C-c C-x r", which isn't bound anymore > since Org 6.26d due to a conflict with bindings in other modes. Looks > like nobody ever used this in the last four years… fixed in maint and > merged to master. Thanks for fixing this! PS: I wonder if *any* of the menu item is used... as I don't use the menu myself, it's hard to tell. -- Bastien ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-16 10:34 ` Bastien @ 2013-02-16 10:39 ` Achim Gratz 2013-02-16 13:18 ` Eric Abrahamsen 2013-02-16 16:19 ` Nick Dokos 1 sibling, 1 reply; 35+ messages in thread From: Achim Gratz @ 2013-02-16 10:39 UTC (permalink / raw) To: emacs-orgmode Bastien writes: > PS: I wonder if *any* of the menu item is used... as I don't use the > menu myself, it's hard to tell. These days I only ever use it for "Show All" which does have a menu entry, but no key binding. But before I got used to where the keys are I often used the menu to do things in tables, so I guess the menu gets good use by other new users of Org (just that apparently none of them tries to "reload Org uncompiled"). 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-16 10:39 ` Achim Gratz @ 2013-02-16 13:18 ` Eric Abrahamsen 2013-02-16 13:23 ` Reloading uncompiled and testing from several git branches (was: Macro question with new texinfo exporter) Bastien 2013-02-16 16:40 ` Macro question with new texinfo exporter Nick Dokos 0 siblings, 2 replies; 35+ messages in thread From: Eric Abrahamsen @ 2013-02-16 13:18 UTC (permalink / raw) To: emacs-orgmode Achim Gratz <Stromeko@nexgo.de> writes: > Bastien writes: >> PS: I wonder if *any* of the menu item is used... as I don't use the >> menu myself, it's hard to tell. > > These days I only ever use it for "Show All" which does have a menu > entry, but no key binding. But before I got used to where the keys are > I often used the menu to do things in tables, so I guess the menu gets > good use by other new users of Org (just that apparently none of them > tries to "reload Org uncompiled"). Related to this -- how do you folks handle multiple local git branches? Do you always run uncompiled, and follow every git checkout with org-reload? I've caught myself several times recently doing git checkouts and reloading, but of course still reloading the byte-compiled files from the previous branch.... ^ permalink raw reply [flat|nested] 35+ messages in thread
* Reloading uncompiled and testing from several git branches (was: Macro question with new texinfo exporter) 2013-02-16 13:18 ` Eric Abrahamsen @ 2013-02-16 13:23 ` Bastien 2013-02-16 14:10 ` Reloading uncompiled and testing from several git branches Achim Gratz 2013-02-16 16:40 ` Macro question with new texinfo exporter Nick Dokos 1 sibling, 1 reply; 35+ messages in thread From: Bastien @ 2013-02-16 13:23 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode (Updating the subject.) Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Related to this -- how do you folks handle multiple local git branches? > Do you always run uncompiled, and follow every git checkout with > org-reload? I've caught myself several times recently doing git > checkouts and reloading, but of course still reloading the byte-compiled > files from the previous branch.... Yes, that's the mistake I often did. Especially because make test compiles the file and do not deleted the compiled files. Maybe we can have make testclean = make test && make clean Achim, would that be useful? I don't compile and I reload with C-u M-x org-reload RET. This way I have no problem switching from one branch to another, provided my setup is not shadowing current variables the wrong way.) -- Bastien ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Reloading uncompiled and testing from several git branches 2013-02-16 13:23 ` Reloading uncompiled and testing from several git branches (was: Macro question with new texinfo exporter) Bastien @ 2013-02-16 14:10 ` Achim Gratz 2013-02-16 14:21 ` Bastien ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Achim Gratz @ 2013-02-16 14:10 UTC (permalink / raw) To: emacs-orgmode Bastien writes: > Yes, that's the mistake I often did. Especially because make test > compiles the file and do not deleted the compiled files. > > Maybe we can have make testclean = make test && make clean > > Achim, would that be useful? We already have "make test-dirty" for testing without doing a compile. However, if you'd rather have that target, you can easily add it to local.mk: .PHONY: testclean # in case you'll ever have a file named "testclean" testclean: test clean In general all such targets that are simple combinations of existing teargets can be added that way. 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Reloading uncompiled and testing from several git branches 2013-02-16 14:10 ` Reloading uncompiled and testing from several git branches Achim Gratz @ 2013-02-16 14:21 ` Bastien 2013-02-16 14:59 ` Eric Abrahamsen 2013-02-17 0:08 ` François Pinard 2 siblings, 0 replies; 35+ messages in thread From: Bastien @ 2013-02-16 14:21 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Hi Achim, Achim Gratz <Stromeko@nexgo.de> writes: > We already have "make test-dirty" for testing without doing a compile. > However, if you'd rather have that target, you can easily add it to > local.mk: > > .PHONY: testclean # in case you'll ever have a file named "testclean" > testclean: test clean > > In general all such targets that are simple combinations of existing > teargets can be added that way. Great, thanks for the tip! I'll use this. -- Bastien ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Reloading uncompiled and testing from several git branches 2013-02-16 14:10 ` Reloading uncompiled and testing from several git branches Achim Gratz 2013-02-16 14:21 ` Bastien @ 2013-02-16 14:59 ` Eric Abrahamsen 2013-02-17 0:08 ` François Pinard 2 siblings, 0 replies; 35+ messages in thread From: Eric Abrahamsen @ 2013-02-16 14:59 UTC (permalink / raw) To: emacs-orgmode Achim Gratz <Stromeko@nexgo.de> writes: > Bastien writes: >> Yes, that's the mistake I often did. Especially because make test >> compiles the file and do not deleted the compiled files. >> >> Maybe we can have make testclean = make test && make clean >> >> Achim, would that be useful? > > We already have "make test-dirty" for testing without doing a compile. > However, if you'd rather have that target, you can easily add it to > local.mk: > > .PHONY: testclean # in case you'll ever have a file named "testclean" > testclean: test clean Thanks for this pointer! ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Reloading uncompiled and testing from several git branches 2013-02-16 14:10 ` Reloading uncompiled and testing from several git branches Achim Gratz 2013-02-16 14:21 ` Bastien 2013-02-16 14:59 ` Eric Abrahamsen @ 2013-02-17 0:08 ` François Pinard 2013-02-18 12:57 ` Nicolas Richard 2013-02-18 19:17 ` Achim Gratz 2 siblings, 2 replies; 35+ messages in thread From: François Pinard @ 2013-02-17 0:08 UTC (permalink / raw) To: emacs-orgmode Achim Gratz <Stromeko@nexgo.de> writes: > .PHONY: testclean # in case you'll ever have a file named "testclean" > testclean: test clean > In general all such targets that are simple combinations of existing > teargets can be added that way. Allow me a pedantic nit-pick, yet nothing so important in practice nowadays. Any Makefile which lists dependencies while expecting them to be satisfied sequentially, one after another, is broken. Make does not (theoretically) guarantee the order, while in practice, all "make" programs I know satisfy dependencies from left to right. In theory, still, "make" and "make -j4" (say) should yield the same actions and effect. Automake-generated Makefiles respect this — or at least, they once did, I did not check in a long while. François P.S. In fact, for the above reason and also for a flurry of other reasons, often related to portability, almost all Makefiles are broken. It is so difficult to get them right that an AM_MAINTAINER_MODE macro has been added to Automake as a way to generate and sanctify incorrect ones. A perfect Makefile is very rare. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Reloading uncompiled and testing from several git branches 2013-02-17 0:08 ` François Pinard @ 2013-02-18 12:57 ` Nicolas Richard 2013-02-18 19:17 ` Achim Gratz 1 sibling, 0 replies; 35+ messages in thread From: Nicolas Richard @ 2013-02-18 12:57 UTC (permalink / raw) To: emacs-orgmode François Pinard <pinard@iro.umontreal.ca> writes: > Any Makefile which lists dependencies while expecting them to be > satisfied sequentially, one after another, is broken. Make does not > (theoretically) guarantee the order, while in practice, all "make" > programs I know satisfy dependencies from left to right. I can then suggest: .PHONY: testclean testclean: test make clean Would that be cleaner ? -- N. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Reloading uncompiled and testing from several git branches 2013-02-17 0:08 ` François Pinard 2013-02-18 12:57 ` Nicolas Richard @ 2013-02-18 19:17 ` Achim Gratz 2013-02-19 1:17 ` François Pinard 1 sibling, 1 reply; 35+ messages in thread From: Achim Gratz @ 2013-02-18 19:17 UTC (permalink / raw) To: emacs-orgmode François Pinard writes: > Any Makefile which lists dependencies while expecting them to be > satisfied sequentially, one after another, is broken. Make does not > (theoretically) guarantee the order, while in practice, all "make" > programs I know satisfy dependencies from left to right. Well, if you're going to pick nits: in this case, nothing is broken. It's known that we're going to use GNU make and that no parallel execution is taking place. Thus we can guarantee that the dependencies will be evaluated in sequence, left to right, just as intended. 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Reloading uncompiled and testing from several git branches 2013-02-18 19:17 ` Achim Gratz @ 2013-02-19 1:17 ` François Pinard 0 siblings, 0 replies; 35+ messages in thread From: François Pinard @ 2013-02-19 1:17 UTC (permalink / raw) To: emacs-orgmode Achim Gratz <Stromeko@nexgo.de> writes: > François Pinard writes: >> Any Makefile which lists dependencies while expecting them to be >> satisfied sequentially, one after another, is broken. Make does not >> (theoretically) guarantee the order, while in practice, all "make" >> programs I know satisfy dependencies from left to right. > Well, if you're going to pick nits: in this case, nothing is broken. > It's known that we're going to use GNU make and that no parallel > execution is taking place. I did not follow these things in years, they might have changed. At some time in the past, GNU packages had to follow GNU standards. We had to write portable Makefiles, could not depend on GNU make, and could not depend on the serial evaluation of dependencies. Many users had things like "MAKEFLAGS=-j4" in their environment, so it blindly applied to all their builds. Maintainers would not know that "no parallel execution is taking place", because it was the installers, and not them, to decide. GNU libc has been the first important GNU package which broke the rule and started to require GNU make; it's true that the GNU libc maintainer and the GNU make maintainer were the same guy. I guess that GNU libc was so late that Richard Stallman allowed that exception. Now that Linux exists, it is very frequent to see packages requiring GNU make, and GNU standards are taken much more lightly than they used to be. Looking at the GNU make documentation, I find something new to me: [If] .NOTPARALLEL is mentioned as a target, then this invocation of make will be run serially, even if the ‘-j’ option is given. Any recursively invoked make command will still run recipes in parallel (unless its makefile also contains this target). Any prerequisites on this target are ignored. So now, the maintainer may prohibit parallelism from his side, and while I did not see that GNU make explicitly guarantees left to right evaluation and execution, the above says "serially" without telling the order. I would be tempted to think that the GNU make documentation is voluntarily silent on the matter, as we may not depend on it. If you depend on the order, you depend on the implementation of Make, not on its specifications. That's why I use the work "broken". All this is academical, and not much important. For a long while now, the effort for correct Makefiles faded away; this cannot be repaired. François ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-16 13:18 ` Eric Abrahamsen 2013-02-16 13:23 ` Reloading uncompiled and testing from several git branches (was: Macro question with new texinfo exporter) Bastien @ 2013-02-16 16:40 ` Nick Dokos 2013-02-16 16:47 ` Nick Dokos 1 sibling, 1 reply; 35+ messages in thread From: Nick Dokos @ 2013-02-16 16:40 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > Achim Gratz <Stromeko@nexgo.de> writes: > > > Bastien writes: > >> PS: I wonder if *any* of the menu item is used... as I don't use the > >> menu myself, it's hard to tell. > > > > These days I only ever use it for "Show All" which does have a menu > > entry, but no key binding. But before I got used to where the keys are > > I often used the menu to do things in tables, so I guess the menu gets > > good use by other new users of Org (just that apparently none of them > > tries to "reload Org uncompiled"). > > Related to this -- how do you folks handle multiple local git branches? > Do you always run uncompiled, and follow every git checkout with > org-reload? I've caught myself several times recently doing git > checkouts and reloading, but of course still reloading the byte-compiled > files from the previous branch.... > I don't trust org-reload enough for that: I write[fn:1] a minimal .emacs that does whatever it needs to do to get me to the problem as fast as possible and start a new emacs (emacs -q -l /path/to/minimal.emacs ...) Nick Footnotes: [fn:1] "Write" is a bit of an exaggeration: I have a standard one that I copy and modify for my current needs. When I'm done, I throw it away. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-16 16:40 ` Macro question with new texinfo exporter Nick Dokos @ 2013-02-16 16:47 ` Nick Dokos 0 siblings, 0 replies; 35+ messages in thread From: Nick Dokos @ 2013-02-16 16:47 UTC (permalink / raw) To: Eric Abrahamsen, emacs-orgmode Nick Dokos <nicholas.dokos@hp.com> wrote: > Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > > > Achim Gratz <Stromeko@nexgo.de> writes: > > > > > Bastien writes: > > >> PS: I wonder if *any* of the menu item is used... as I don't use the > > >> menu myself, it's hard to tell. > > > > > > These days I only ever use it for "Show All" which does have a menu > > > entry, but no key binding. But before I got used to where the keys are > > > I often used the menu to do things in tables, so I guess the menu gets > > > good use by other new users of Org (just that apparently none of them > > > tries to "reload Org uncompiled"). > > > > Related to this -- how do you folks handle multiple local git branches? > > Do you always run uncompiled, and follow every git checkout with > > org-reload? I've caught myself several times recently doing git > > checkouts and reloading, but of course still reloading the byte-compiled > > files from the previous branch.... > > > > I don't trust org-reload enough for that: I write[fn:1] a minimal .emacs > that does whatever it needs to do to get me to the problem as fast as > possible and start a new emacs (emacs -q -l /path/to/minimal.emacs ...) > I do ``make clean'' early and often too... ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-16 10:34 ` Bastien 2013-02-16 10:39 ` Achim Gratz @ 2013-02-16 16:19 ` Nick Dokos 2013-02-16 17:37 ` Thomas S. Dye 1 sibling, 1 reply; 35+ messages in thread From: Nick Dokos @ 2013-02-16 16:19 UTC (permalink / raw) To: Bastien; +Cc: Achim Gratz, emacs-orgmode Bastien <bzg@altern.org> wrote: > PS: I wonder if *any* of the menu item is used... as I don't use the > menu myself, it's hard to tell. > I do: there are many things I use rarely[fn:1] (e.g. archiving, drawers, properties, even marking TODOs outside the agenda: was that C-c t or C-c C-t now?) that I have not got into my finger memory. The menu is a useful crutch for me in those cases: I use the menu the first time, put the key chord into short-term memory and forget about it as soon as I'm done. Two weeks later, I start from scratch :-) Nick Footnotes: [fn:1] An imprecise term, but for me that means "less often than once a week". YMMV. And as one gets older, that mileage changes - DAMHIKT :-) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-16 16:19 ` Nick Dokos @ 2013-02-16 17:37 ` Thomas S. Dye 0 siblings, 0 replies; 35+ messages in thread From: Thomas S. Dye @ 2013-02-16 17:37 UTC (permalink / raw) To: nicholas.dokos; +Cc: Bastien, Achim Gratz, emacs-orgmode Nick Dokos <nicholas.dokos@hp.com> writes: > Bastien <bzg@altern.org> wrote: > >> PS: I wonder if *any* of the menu item is used... as I don't use the >> menu myself, it's hard to tell. >> > > I do: there are many things I use rarely[fn:1] (e.g. archiving, drawers, > properties, even marking TODOs outside the agenda: was that C-c t or C-c > C-t now?) that I have not got into my finger memory. The menu is a > useful crutch for me in those cases: I use the menu the first time, > put the key chord into short-term memory and forget about it as soon > as I'm done. Two weeks later, I start from scratch :-) > > Nick > > Footnotes: > > [fn:1] An imprecise term, but for me that means "less often than once a week". > YMMV. And as one gets older, that mileage changes - DAMHIKT :-) My experience resembles Nick's. The menus save me lots of time. I'm not sure what DAMHIKT means, but there is no doubt that mileage changes with age. The term "key chord" puzzled me for a long time, until a colleague pointed out that it is possible to "play" a computer running Emacs, just like playing a piano. I was stunned! All the best, Tom -- Thomas S. Dye http://www.tsdye.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-04 15:43 ` Thomas S. Dye 2013-02-04 17:26 ` Bastien @ 2013-02-04 18:10 ` Nicolas Goaziou 2013-02-04 18:48 ` Thomas S. Dye 2013-02-04 18:38 ` Achim Gratz 2 siblings, 1 reply; 35+ messages in thread From: Nicolas Goaziou @ 2013-02-04 18:10 UTC (permalink / raw) To: Thomas S. Dye; +Cc: Bastien, Org-mode Hello, tsd@tsdye.com (Thomas S. Dye) writes: > Nicolas Goaziou <n.goaziou@gmail.com> writes: > >> Bastien <bzg@altern.org> writes: >> >>> Now back to the issue at hand, what about simply allowing to escape >>> the , and " characters? This was Thomas first try, and a natural one >>> I'd say. >> >> I have pushed a fix in maint for that. It should now be possible to use >> {{{kbd(C-\,)}}} to get "C-," as argument. > > I need a bit more help with this. I created a tracking branch for > maint: > > git branch --track maint origin/maint > > Then, I checkout maint: > > git checkout maint > > Reloading Org yields these messages: > > The following features were found in load-path, please check if that's correct: > (org-e-texinfo org-export) > Some error occured while reloading Org features > (ob-core ob-tcl) > Please check *Messages*! > Org-mode version 7.9.3e (7.9.3e @ /Users/dk/.emacs.d/src/org-mode/lisp/) > cond: Symbol's function definition is void: org-e-latex-export-to-latex > > I'm stymied here. I'd like to be able to use the new macro code with > the new exporter. How is that possible? The experimental exporter can be found in master branch. The maint branch has a very old version which is unusable. I pushed the fix to maint because it was about Elements, not directly the exporter. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-04 18:10 ` Nicolas Goaziou @ 2013-02-04 18:48 ` Thomas S. Dye 0 siblings, 0 replies; 35+ messages in thread From: Thomas S. Dye @ 2013-02-04 18:48 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Bastien, Org-mode Nicolas Goaziou <n.goaziou@gmail.com> writes: > > I pushed the fix to maint because it was about Elements, not directly > the exporter. Oh, I see now. You pushed the fix to maint, then merged branch 'maint' with master, so the fix is there as well. I didn't understand the workflow, so the reference to maint confused me. All the best, Tom -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-04 15:43 ` Thomas S. Dye 2013-02-04 17:26 ` Bastien 2013-02-04 18:10 ` Nicolas Goaziou @ 2013-02-04 18:38 ` Achim Gratz 2013-02-04 20:21 ` Thomas S. Dye 2 siblings, 1 reply; 35+ messages in thread From: Achim Gratz @ 2013-02-04 18:38 UTC (permalink / raw) To: emacs-orgmode Thomas S. Dye writes: > Then, I checkout maint: > > git checkout maint I'm not sure what your starting point is, but you'd almost certainly will want to create the correct autoloads. In fact, you'd have a much better chance of this working correctly if you took the time (just once) to set up an install location and then just do a "make up2" or something similar whenever you want to update. > Reloading Org yields these messages: > > The following features were found in load-path, please check if that's correct: > (org-e-texinfo org-export) So did you check that those features were found in the right place? > Some error occured while reloading Org features > (ob-core ob-tcl) > Please check *Messages*! What were those messages? And since the presence of both features indicates that you were previously on master, why did you switch to maint at all (everything on maint should have been merged into master)? > Org-mode version 7.9.3e (7.9.3e @ /Users/dk/.emacs.d/src/org-mode/lisp/) > cond: Symbol's function definition is void: org-e-latex-export-to-latex > > I'm stymied here. I'd like to be able to use the new macro code with > the new exporter. How is that possible? Just update master. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Macro question with new texinfo exporter 2013-02-04 18:38 ` Achim Gratz @ 2013-02-04 20:21 ` Thomas S. Dye 0 siblings, 0 replies; 35+ messages in thread From: Thomas S. Dye @ 2013-02-04 20:21 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Aloha Achim, Achim Gratz <Stromeko@nexgo.de> writes: > > What were those messages? And since the presence of both features > indicates that you were previously on master, why did you switch to > maint at all (everything on maint should have been merged into master)? > >> Org-mode version 7.9.3e (7.9.3e @ /Users/dk/.emacs.d/src/org-mode/lisp/) >> cond: Symbol's function definition is void: org-e-latex-export-to-latex >> >> I'm stymied here. I'd like to be able to use the new macro code with >> the new exporter. How is that possible? > > Just update master. Thanks for looking into this. Yes, this was my confusion. I didn't understand that maint was merged with master. I thought Nicolas' reference to maint was an indication that I had to use the new code there. All the best, Tom -- Thomas S. Dye http://www.tsdye.com ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2013-02-19 1:17 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-28 20:19 Macro question with new texinfo exporter Thomas S. Dye 2013-01-29 18:21 ` Nicolas Goaziou 2013-01-29 18:49 ` Thomas S. Dye 2013-01-30 9:22 ` Bastien 2013-01-30 12:44 ` Nicolas Goaziou 2013-01-30 16:14 ` Bastien 2013-01-30 22:24 ` Nicolas Goaziou 2013-01-31 2:21 ` Thomas S. Dye 2013-01-31 13:51 ` Bastien 2013-01-31 13:58 ` Nicolas Goaziou 2013-01-31 21:23 ` Nicolas Goaziou 2013-02-04 15:43 ` Thomas S. Dye 2013-02-04 17:26 ` Bastien 2013-02-04 18:57 ` Achim Gratz 2013-02-16 9:21 ` Bastien 2013-02-16 10:19 ` Achim Gratz 2013-02-16 10:34 ` Bastien 2013-02-16 10:39 ` Achim Gratz 2013-02-16 13:18 ` Eric Abrahamsen 2013-02-16 13:23 ` Reloading uncompiled and testing from several git branches (was: Macro question with new texinfo exporter) Bastien 2013-02-16 14:10 ` Reloading uncompiled and testing from several git branches Achim Gratz 2013-02-16 14:21 ` Bastien 2013-02-16 14:59 ` Eric Abrahamsen 2013-02-17 0:08 ` François Pinard 2013-02-18 12:57 ` Nicolas Richard 2013-02-18 19:17 ` Achim Gratz 2013-02-19 1:17 ` François Pinard 2013-02-16 16:40 ` Macro question with new texinfo exporter Nick Dokos 2013-02-16 16:47 ` Nick Dokos 2013-02-16 16:19 ` Nick Dokos 2013-02-16 17:37 ` Thomas S. Dye 2013-02-04 18:10 ` Nicolas Goaziou 2013-02-04 18:48 ` Thomas S. Dye 2013-02-04 18:38 ` Achim Gratz 2013-02-04 20:21 ` Thomas S. Dye
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).