Macro question with new texinfo exporter

Macro question with new texinfo exporter

[Thomas S. Dye]

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

Re: Macro question with new texinfo exporter

[Nicolas Goaziou]

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

Re: Macro question with new texinfo exporter

[Thomas S. Dye]

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

Re: Macro question with new texinfo exporter

[Bastien]

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

Re: Macro question with new texinfo exporter

[Nicolas Goaziou]

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

Re: Macro question with new texinfo exporter

[Bastien]

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

Re: Macro question with new texinfo exporter

[Nicolas Goaziou]

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

Re: Macro question with new texinfo exporter

[Thomas S. Dye]

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

Re: Macro question with new texinfo exporter

[Bastien]

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

Re: Macro question with new texinfo exporter

[Nicolas Goaziou]

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

Re: Macro question with new texinfo exporter

[Nicolas Goaziou]

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

Re: Macro question with new texinfo exporter

[Thomas S. Dye]

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

Re: Macro question with new texinfo exporter

[Bastien]

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

Re: Macro question with new texinfo exporter

[Nicolas Goaziou]

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

Re: Macro question with new texinfo exporter

[Achim Gratz]

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

Re: Macro question with new texinfo exporter

[Thomas S. Dye]

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

Re: Macro question with new texinfo exporter

[Achim Gratz]

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

Re: Macro question with new texinfo exporter

[Thomas S. Dye]

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

Re: Macro question with new texinfo exporter

[Bastien]

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

Re: Macro question with new texinfo exporter

[Achim Gratz]

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

Re: Macro question with new texinfo exporter

[Bastien]

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

Re: Macro question with new texinfo exporter

[Achim Gratz]

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

Re: Macro question with new texinfo exporter

[Eric Abrahamsen]

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....

Reloading uncompiled and testing from several git branches (was: Macro question with new texinfo exporter)

[Bastien]

(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

Re: Reloading uncompiled and testing from several git branches

[Achim Gratz]

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

Re: Reloading uncompiled and testing from several git branches

[Bastien]

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

Re: Reloading uncompiled and testing from several git branches

[Eric Abrahamsen]

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!

Re: Macro question with new texinfo exporter

[Nick Dokos]

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 :-)

Re: Macro question with new texinfo exporter

[Nick Dokos]

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.

Re: Macro question with new texinfo exporter

[Nick Dokos]

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...

Re: Macro question with new texinfo exporter

[Thomas S. Dye]

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

Re: Reloading uncompiled and testing from several git branches

[François Pinard]

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.

Re: Reloading uncompiled and testing from several git branches

[Nicolas Richard]

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.

Re: Reloading uncompiled and testing from several git branches

[Achim Gratz]

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

Re: Reloading uncompiled and testing from several git branches

[François Pinard]

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