Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

2020-10-29 Thread Achim Gratz
Berry, Charles" via "General discussions about Org-mode. writes:
> FWIW, it doesn't seem like an accident. You might ping the author of this 
> commit:

No, that change was to suppress an _additional_ confirmation that was
triggered by some internal implementation details.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: [O] join two or more tables

2019-08-23 Thread Achim Gratz
Uwe Brauer writes:
> Hm, thanks but could you post an example (the one I finally used is
> based on R and goes as follows

There's a whole tutorial on table manipulation on Worg:
https://orgmode.org/worg/org-contrib/babel/examples/lob-table-operations.html

It's a bit old so some of the functions may be named differently now,
but the principles should still apply.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




Re: [O] join two or more tables

2019-08-18 Thread Achim Gratz
Uwe Brauer writes:
> Thanks I knew about it, but it seems very sophisticated and column, not
> row based.

Well, if simple-minded suits you (i.e. the columns are known to have the
same order):

Tables in Org are lists with rows as their elements, and a row is either
a symbol or a list of column elements.  So just concatenating the two
lists does (almost) the right thing.  If you know the row has headers,
you need to skip until the first real data row in the second table
(i.e. skip the first row, the first header and then resume the concat).

Your other option is just grabbing the text of both tables, emit it as a
single entity (again you may want to remove the header on the second
table) and then call org-align-table on it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: [O] Proposal for new document-level syntax

2019-06-01 Thread Achim Gratz
Fraga, Eric writes:
> For me, however, your proposed structure would clash strongly with my
> usual working practice.  Specifically, I put all customizations and
> settings at the end of my documents, along with, for instance, Emacs
> file local variables.  These are things I do not change often and
> usually don't care to see.  At the start of the document, however, is
> the real content.  So, I don't particularly like the idea of having
> settings etc. *before* the content in my files.

If the customization data isn't visible by default, does that address
your concerns?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves




Re: [O] [PATCH] Ruby tests

2019-05-15 Thread Achim Gratz
Nicolas Goaziou writes:
>> Ruby tests have been failing for quite some time, here's my fix.
>
> Feel free to push these changes if they fix tests for you.

I no longer have the commit bit since the server software was changed.
If it still requires an account on the server then I don't intend to
create one, either.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




[O] [PATCH] Ruby tests

2019-05-12 Thread Achim Gratz

Ruby tests have been failing for quite some time, here's my fix.

>From 2f1bbaab939f6b6ceceb72862470e0576a8e2cba Mon Sep 17 00:00:00 2001
From: Achim Gratz 
Date: Sun, 12 May 2019 13:14:04 +0200
Subject: [PATCH 1/1] test-ob-ruby.el: fix tests

* testing/lisp/test-ob-ruby.el: Output no longer contains a trailing
  newline, remove from the template to compare against.  Session must
  be named for the tests to actually work, also add some extra code to
  ascertain that the code after the output statement has actually run
  in the session.
---
 testing/lisp/test-ob-ruby.el | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/testing/lisp/test-ob-ruby.el b/testing/lisp/test-ob-ruby.el
index f42987b639..4d676fe19a 100644
--- a/testing/lisp/test-ob-ruby.el
+++ b/testing/lisp/test-ob-ruby.el
@@ -22,57 +22,58 @@
   (signal 'missing-test-dependency "Support for Ruby code blocks"))
 
 (ert-deftest test-ob-ruby/session-output-1 ()
-(should (equal (org-test-with-temp-text "#+begin_src ruby :session :results output
+(should (equal (org-test-with-temp-text "#+begin_src ruby :session org-test-ruby :results output
 s = \"1\"
 s = \"2\"
 s = \"3\"
 puts s
+s = \"4\"
 #+end_src"
   (org-babel-execute-maybe)
   (substring-no-properties
(buffer-string)))
-		   "#+begin_src ruby :session :results output
+		   "#+begin_src ruby :session org-test-ruby :results output
 s = \"1\"
 s = \"2\"
 s = \"3\"
 puts s
+s = \"4\"
 #+end_src
 
 #+RESULTS:
 : 3
-
 ")))
 (ert-deftest test-ob-ruby/session-output-2 ()
-(should (equal (org-test-with-temp-text "#+begin_src ruby :session :results output
-s = \"5\"
+(should (equal (org-test-with-temp-text "#+begin_src ruby :session org-test-ruby :results output
 puts s
+s = \"5\"
 #+end_src"
   (org-babel-execute-maybe)
   (substring-no-properties
(buffer-string)))
-		   "#+begin_src ruby :session :results output
-s = \"5\"
+		   "#+begin_src ruby :session org-test-ruby :results output
 puts s
+s = \"5\"
 #+end_src
 
 #+RESULTS:
-: 5
-
+: 4
 ")))
 (ert-deftest test-ob-ruby/session-output-3 ()
-(should (equal (org-test-with-temp-text "#+begin_src ruby :session :results output
+(should (equal (org-test-with-temp-text "#+begin_src ruby :session org-test-ruby :results output
 puts s
+s = \"6\"
 #+end_src"
   (org-babel-execute-maybe)
   (substring-no-properties
(buffer-string)))
-		   "#+begin_src ruby :session :results output
+		   "#+begin_src ruby :session org-test-ruby :results output
 puts s
+s = \"6\"
 #+end_src
 
 #+RESULTS:
 : 5
-
 ")))
 
 (provide 'test-ob-ruby)
-- 
2.21.0



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


Re: [O] [PATCH] Fix behaviour of ":dir" when ":mkdirp" is not defined

2019-04-28 Thread Achim Gratz

Am 24.04.2019 um 12:43 schrieb Joaquín Aguirrezabalaga:

   #+begin_src elisp :dir /tmp/some-test-dir :mkdirp t
   default-directory
   #+end_src


Do not hardcode "/tmp" in the tests.


--
Achim.

(on the road :-)




Re: [O] OT: gmane seems to be back

2018-10-31 Thread Achim Gratz

Am 30.10.2018 um 16:57 schrieb Nick Dokos:

For a couple of weeks, I had not been able to connect to gmane, so I
finally gave up and changed my preferences so that I could receive the
email from the list.  I have not seen any acknowledgement anywhere
that it was down BTW - did anybody here notice? Or was it just me?


Plain NNTP wasn't down at all, but connections that use TLS stopped 
working some time ago and probably still don't work.



--
Achim.

(on the road :-)




Re: [O] Testing master branch

2018-04-29 Thread Achim Gratz
Bernt Hansen writes:
> I intend to update and track the master branch git repo changes daily in
> order to identify problems as early as possible.
>
> Does it matter if I compile or not for this?
>
> Normally I do:
>
> git pull
> make
> and restart emacs every morning
>
> Can I do make uncompiled instead and skip the restart?

I fail to see how the two are related, unless you are talking about
compiling a new Emacs every morning.

> What do you recommend?

make up2

Then re-load org in your running Emacs session or restart Emacs as you
wish.  Note that the up2 target does not install anything if any of the
tests failed.  If you want to live dangerously, skip the tests and
install whatever you've got, use the update2 target.


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] [RFC] Moving "manual.org" into core

2018-03-06 Thread Achim Gratz
Bastien Guerry writes:
>> Exactly. Emacs will anyways ship with org.texi. So moving the manual
>> source to Org in the Org repo shouldn't concern the Emacs repo.
>
> Yes, but it is still a concern for Emacs contributors like Glenn and
> others who occasionnally make corrections in Emacs' org.texi.  I'm
> fine if we can backport these corrections by hand for the time being.

We'll have to deal with them just like we deal with all other
backporting from Emacs.  It's no secret that Emacs like to do things in
a slightly different way and that had to be accepted when Org was moved
into Emacs, but development kept going seperately from it.

I haven't looked at how often changes to Org's manual actually originate
on the Emacs side in one development cycle of Emacs (which is generally
a year or more, but it can't be that much.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html




Re: [O] [RFC] Moving "manual.org" into core

2018-03-05 Thread Achim Gratz
Nicolas Goaziou writes:
>> Testing the process of running "make pdf" while emacs will in charge
>> of producing a PDF file (.org => .texi => .pdf) will be interesting,
>> and potentially more error-prone than the current .texi=>.pdf process.
>
> I didn't invest time in the Makefile, so I don't know.

I've posted a working Makefile back when Thomas was working on the
manual and it is still working with minimal modifications.  If you
decide you want to have this (and exactly which way) I'm sure that can
be further refined in a matter of days (not weeks) to everyones
satisfaction if that should be necessary.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] [RFC] Moving "manual.org" into core

2018-01-22 Thread Achim Gratz
Bastien Guerry writes:
>> Why do we need it? If it is mandatory (I fail to see why, since we
>> provide the source of the info file), can we include it read-only?
>
> It is mandatory, as long as the GNU standard for documentation is to
> provide it as a .texi file.

It can always be generated for the Emacs export.  But it should cease to
exist in the Git repo since it becomes a derivative of manual.org.

> I don't think providing it read-only is a good idea: people should be
> able to edit it and provide patches against it, even though we prefer
> to encourage patches against manual.org.

No, I'd strongly discourage that and accept such edits only in
exceptional cases.  If the source file is manual.org, all patches or
other changes need to be against the source.  You wouldn't accept
patches to the PDF of the manual or any such thing, do you?


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: [O] [RFC] Moving "manual.org" into core

2018-01-20 Thread Achim Gratz
Nicolas Goaziou writes:
> Actually, I have another idea. We could implement a function generating
> the manual, right in Org core. It can be useful for both packaging, like
> the above, and for developers, who can update the manual on the fly.

That should go into mk/org-fixup.el then.  I am not aware that any
packagers have actually picked those helper functions up, so the primary
aim should still be that "make doc" keeps things updated.

> Assuming the function above is called `org-generate-manuals', and
> manual.org is located in doc/, what changes would be needed? I assume
> they would be minimal.
>
>> ORG2HTML=-f org-html-export-to-html
>
> I think HTML should still be generated from the texi file. I assume
> there is some compatibility to preserve among GNU manuals.

We could and probably should provide an option for doing it both ways.
The intent back when was that sometimes one of the export paths did work
while the other didn't, so it was quite useful to have both available.

>> ORG2INFO=--eval "(org-texinfo-compile \"./$<\")"
>
> See above.

As I said, all of this is several years old and still working.

> What kind of modifications do you have in mind?

Nothing, unless we find something missing or wrong.  But at least we
need to check that it works 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: [O] [RFC] Moving "manual.org" into core

2018-01-20 Thread Achim Gratz
Nicolas Goaziou writes:
> "manual.org" was updated a month ago, and, so far, nobody complained
> about it. So, I think it's a good time to discuss about what could be
> done next.

The lack of complaints is unlikely to mean that everybody tried it and
found nothing to complain about.  I haven't had much time to do anything
with it so far, but I did at least check that I could use the build
system extension that I created while Tom was working on his version
with it.  The export to texi is still relatively slow, but since I have
a much faster machine now it works OK for me.  I have not yet tried how
long it would take on my old machine.

> The first obvious step is to move the file into "doc/" directory. Then
> I assume we could delete "org.texi" and "org.info" there and generate
> new ones from the Org file. For example, the following command, called
> from the "manual.org" file,
>
> (let ((org-texinfo-logfiles-extensions
>(cons "texi" org-texinfo-logfiles-extensions)))
>   (org-texinfo-export-to-info))
>
> produces an "org.info" file without an "org.texi". It thus prevents
> direct editing of "org.texi". I assume this could be called by "make
> info" target.

Maybe not directly in the way you show it here, but yes. 

For the record, the build system extension from years ago involves
creating a directory orgmanual, then you should symlink orgmanual.org to
the actual file in contrib/, then put the follwing Makefile there:

--8<---cut here---start->8---
TEXI2PDF+=--tidy
BEXP=$(BATCH) \
--eval '(add-to-list '"'"'load-path "../lisp")' \
--eval '(setq org-footnote-auto-adjust nil)'
EXTEXI= -l ox-texinfo \
--eval '(add-to-list '"'"'org-export-snippet-translation-alist 
'"'"'("info" . "texinfo"))'
EXHTML= -l ox-html \
$(BTEST_POST) \
--eval '(add-to-list '"'"'org-export-snippet-translation-alist 
'"'"'("info" . "texinfo"))'
ORG2TEXI=-f org-texinfo-export-to-texinfo
ORG2HTML=-f org-html-export-to-html
ORG2INFO=--eval "(org-texinfo-compile \"./$<\")"

.SUFFIXES:  # we don't need default suffix rules
ifeq ($(MAKELEVEL), 0)
  $(error This make needs to be started as a sub-make from the toplevel 
directory.)
endif
.PHONY: all info html pdf

all:$(ORG_MAKE_DOC)

info:   org.info

html:   orgmanual org.html

pdf:org.pdf

org.texi:   orgmanual.org
$(BEXP) $(EXTEXI) $< $(ORG2TEXI)
org.info:   org.texi
$(MAKEINFO)  --no-split $< -o $@
# LANG=C # to work around a bug in texi2dvi
org.pdf:LC_ALL=C
org.pdf:LANG=C
org.pdf:org.texi
$(TEXI2PDF) $<
orgmanual:  org.texi
$(TEXI2HTML) $< -o $@
org.html: orgmanual.org
$(BEXP) $(EXHTML) $< $(ORG2HTML)

clean:
$(RM) org org.t2d *.pdf *.html *.texi *.info *~ \
  *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.pg *.pgs \
  *.toc *.tp *.tps *.vr *.vrs *.log *.html *.ps
cleanall:   clean
$(RMR) org.t2d orgmanual

--8<---cut here---start->8---

Then add the following to local.mk

--8<---cut here---end--->8---
.PHONY: orgmanual
EXTRADIRS=orgmanual
orgmanual:
$(MAKE) -C $@
manclean:
$(MAKE) -C orgmanual clean
mancleanall:
$(MAKE) -C orgmanual cleanall
clean:  manclean
cleanall:   mancleanall
--8<---cut here---end--->8---

You can now say "make orgmanual" and have it do the right thing.  YOu
could even further extend local.mk so that the "doc" target includes the
new manual by adding this line:

--8<---cut here---end--->8---
doc:orgmanual
--8<---cut here---end--->8---

The whole thing can easily be adapted to work in doc/ if it gets decided
that we should switch to manual.org (or better org.org maybe) as our
primary source file.

> So basically, the idea would be to not provide anymore an "org.texi"
> file. Only "manual.org" and "org.info". Emacs developers already apply
> fixes to ORG-NEWS, which is a plain Org file, so I guess it would not
> make their life harder if "manual.org" replaces "org.texi".

Yes, once the org file is our primary source we should stop provding the
texi file in Git at least.  I don't have any preference w.r.t. whether
an Org release tarball should still contain an org.texi or not, but
that's a separate decision.  I suspect that not delivering it would
inconvenience at least the Debian folks somewhat since they keep
insisting to use their own build recipes last I looked.  Last but not
least we'll have to check if we need any modifications for the ELPA
distributions.


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] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

2018-01-04 Thread Achim Gratz
Kaushal Modi writes:
> No, the keys didn't transfer. As Bastien mentioned in the original email,
> you need to create an account on code.orgmode.org first (pasted the
> instructions below):

I've seen that, but I was asking firstly about the clone operation.  In
this case, the website shouldn't advertise

g...@code.orgmode.org:bzg/org-mode.git

as a possible clone URL at all when no user is signed in.

Also, I really don't want to create yet another account, the SSH key
should be enough (as it was before).  Then of course the whole
"Register/Sign In" as well as Issues, Pull Requests and Wiki on the
website shouldn't be there either.


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: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

2018-01-04 Thread Achim Gratz
Bastien Guerry writes:
>> ~$ git clone g...@code.orgmode.org:bzg/org-mode.git
>^^^
>
> This is for when you have an account on code.orgmode.org and want
> to clone through ssh.

Have the existing SSH keys been migrated to the new server?  Trying to
clone through this method keeps asking me for a password.


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] org-plus-contrib tar disappeared from orgmode.org/elpa/

2018-01-04 Thread Achim Gratz
Christopher League writes:
> I'm using NixOS, and my current nixpkgs tree refers to 20170911, which
> cannot (re)-build now because the source is missing. Here's the Nix
> specification referencing the now-broken URL:
>
> 

Frankly, that's a setup you simply shouldn't be using.  Create a
(shallow) clone from Git and arrange for ORG_ADD_CONTRIB to pull in
whatever you really _need_ from contrib.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

2017-12-31 Thread Achim Gratz

Am 30.12.2017 um 12:57 schrieb Bastien:

So if you want to open a discussion on better hosting plans and if you
or someone else is willing to handle the migration and to maintain the
server afterwards, we can of course discuss this.


As I said, the decision's done, so let's see how things work out.  If 
there are problems we need to figure it out anyway and if there aren't, 
then I suggest we'll just keep it going.



--
Achim.

(on the road :-)




Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

2017-12-30 Thread Achim Gratz

Am 29.12.2017 um 13:26 schrieb Bastien Guerry:

Migrating to a new vultr instance was easier than trying to upgrade
the rackspace hosting service and the vultr pricing is better.


It's water under the bridge now, but if there had been a discussion here 
we might have converged to a different solution.



--
Achim.

(on the road :-)




Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

2017-12-29 Thread Achim Gratz

Am 28.12.2017 um 18:12 schrieb Bastien Guerry:

thanks to Jason Dunsmore, we were able to have our orgmode.org server
sponsored by Rackspace.  Their OSS hosting program ends by the end of
the year¹.  Thanks a lot to Rackspace for this program, it saved us a
lot of money!  And to Jason for letting us know about it.


And if you'd read through the entirety of the Register article you 
linked to you'd find that presumably any existing OSS hosting would 
continue to be free, so why exactly does Org need to migrate?


--
Achim.

(on the road :-)




Re: [O] Git repository error

2017-12-19 Thread Achim Gratz
Nick Dokos writes:
> You might not have given it enough time. Here, it takes a long time,
> but it completes:
>
> $ time git clone http://orgmode.org/org-mode.git
> Cloning into 'org-mode'...

Yes, http:// works (if slowly), but git:// is really flakey and mostly
doesn't during the last few days at least.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




Re: [O] Bug?? #+begin_src sh :file

2017-09-16 Thread Achim Gratz
Charles Millar writes:
> A bug? Or what am I missing?

You are creating a file that Org is supposed to fill with the output
from your script.  Your script doesn't produce output, but instead
writes to the same file.  When the script returns, Org dutifully
truncates the file to nothing.


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] Old org.el ending up in current tar packages?

2017-08-23 Thread Achim Gratz
Adam Porter writes:
> It seems that org.el in org-20170821.tar is out of date.  Sharon Kimble
> noticed that something was wrong, and after much digging, we found that
> org-clock.el has been updated to have calls to
> org-time-string-to-seconds with 2 arguments, but the function definition
> in org.el only takes 1 argument.
>
> This is very strange, because the addition of the extra arg to
> org-time-string-to-seconds was made back on July 7, and that
> introduced

That change is only on master, so whatever trouble you are seeing in the
ELPA tarball is unrelated to that change.

> a bug which was fixed in org-clock.el on August 5, yet the tarball from
> August 21 has the pre-July 7 org-time-string-to-seconds function.

That fix was introduced on maint and merged to master, which seems to be
in error since the bug was in master only.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] make compile fails

2017-08-20 Thread Achim Gratz
Jarmo Hurri writes:
> Running 'make cleanall' didn't help.

Yes, because you need to install htmlize most likely (if you need it at
all).  I installed the one from Marmalade.  You need to activate it for
testing (since during test local packages are not visible by default):

BTEST_POST  = --eval '(add-to-list '"'"'load-path 
"~/.emacs.d/elpa/htmlize-1.39")'

(if there is already something in BTEST_POST defined, then _add_ this by
using '+=' instead of '='.

> However, a fresh clone followed by a reconfiguration of local.mk solved
> the issue. Most likely the result of a local.mk that is no longer
> consistent.

Ugh, this isn't Windows, you know?  There is really nothing that you can
achieve by re-cloning that you couldn't achieve in a better way without
it.  In your case, just realizing that it was htmlize that was missing
and removing that from your local customization would have been
sufficient.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: [O] ox-taskjuggler on MELPA useful despite org-plus-contrib

2017-08-09 Thread Achim Gratz
Adam Porter writes:
> I've had the same problem, I have to manually delete the extra org
> package now and then.  I wonder if a dummy package would prevent
> package.el from reinstalling it...

Yes it does and I've provided instructions on how to do that quite some
time ago on this list.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] Versioning of worg content

2017-07-03 Thread Achim Gratz
Bastien writes:
> No.  Worg needs love.  And yes, we could tag Worg's repository
> with Org-mode versions, the same as we would do with documentation.

If you are talking about the Git repository behind Worg, then:

a) Yes, we could give that repository version tags.
b) No, we shouldn't do that unless SomeOne™ keeps all of Worg consistent
with the Org releases.

If you are saying instead that the examples in Worg should be annotated
with the Org version that they were provided for (or last tested to be
working at), that would be good, but see b) above.


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: link formating problem [9.0.5 (9.0.5-elpaplus @ /Users/mistkafka/.emacs.d/elpa/org-plus-contrib-20170210/)]

2017-05-27 Thread Achim Gratz
Chunyang Xu writes:
> Sure, I will do that when it is possible (Right now, I can not git-clone
> org-mode's repository,
>
> ~$ git clone git://orgmode.org/org-mode.git
> Cloning into 'org-mode'...
> fatal: read error: Connection reset by peer

Cloning via http still works, so try that instead.

> and the mirror at http://repo.or.cz/w/org-mode.git is also outdated for
> about 4 days).

That most likely hits the same problem, which seems to be with the
orgmode.org server.


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] More clocktable breakage

2017-05-15 Thread Achim Gratz
Nicolas Goaziou writes:
> Is your issue solved?

I can confirm the issue is solved.  Thanks again.


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: [O] More clocktable breakage

2017-05-14 Thread Achim Gratz
Nicolas Goaziou writes:
> I fixed the issue by extending `org-at-timestamp-p' optional argument
> while preserving backward-compatibility.

Thanks.  That seems like a much better soultion than what we've had
before and some of what we've discussed before getting there.

> Is your issue solved?

I'll have final confirmation sometime next week, but I assume yes.


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: [O] More clocktable breakage

2017-05-07 Thread Achim Gratz
Nicolas Goaziou writes:
> OK. I inserted it in a fresh Org buffer. Is there any command to call on
> it now?

Yes, put the cursor on the date or time of one of the timestamps and
press S-Up or S-Down.  It should increase or decrease the corresponding
element of the timestamp, but instead you'll get an error message:

org-clocktable-shift: Line needs a :block definition before this command works

which appears because the timestamp wasn't recognized and the
fallthrough of org-shift* then tries to apply another function that
deals with the :block argument (which isn't present here and shouldn't
be).

>> Sometimes org-element-context recognizes the clocktable as a paragraph
>> instead of dynamic-block
>
> FWIW, I get `dynamic-block'.

OK, then that should get you the same error.

>> (I've not yet figured out why and it isn't vary reproducible, but it
>> must have something to do with the cache since it goes away when
>> I reload the file)
>
> It is possible, indeed. You can also use M-x org-element-cache-reload to
> check this. However, cache is disabled by default, so the problem
> shouldn't appear in normal usage.

I have not enabled any cache that I know of.  All I can say is that
sometimes the clocktable doesn't get recognized as dynamic-block but a
paragraph instead.  That re-enables the recognition of the timestamp
incidentally (why exactly I don't really understand), which was why I
couldn't reproduce the error at home for some time.

> I start to think that there is no bug in clock tables (but certainly in
> the cache mechanism, probably related to some `before-change-functions'
> and `after-change-functions' misuse there).

I'm not using any of those unless they already come with Emacs or Org.


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] More clocktable breakage

2017-05-06 Thread Achim Gratz
> As I asked 5 weeks ago (!), could you provide an ECM demonstrating the
> issue so that I can fix it, in the light of our discussion?

I've told you from the beginning that it was a file at work and that it
would take some time to dig down to the problem since it did work at
home when I tried to create said ECM.  After a few false starts
(thinking that it was Windows vs. Linux and the local configurations on
each side) I've finally converged to this (just insert a new clocktable,
then replace the default parameters with tstart/tend):

--8<---cut here---start->8---
  #+BEGIN: clocktable :tstart "<2017-03-24 Fri 00:00>" :tend "<2017-04-23 Sat 
23:45>"
  #+CAPTION: Clock summary at [2017-05-06 Sat 11:09]
  | L | Headline | Time   |   |
  |---+--++---|
  |   | *Total time* | *0:00* |   |
  #+END:
--8<---cut here---end--->8---

Sometimes org-element-context recognizes the clocktable as a paragraph
instead of dynamic-block (I've not yet figured out why and it isn't vary
reproducible, but it must have something to do with the cache since it
goes away when I reload the file) and then 'timestamp gets returned when
the cursor is on one of the timestamps.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] More clocktable breakage

2017-05-02 Thread Achim Gratz
Nicolas Goaziou writes:
>> I'd say anything org-element-* should exclusively return syntactical
>> things.  Context dependence needs to be dealt with elsewhere.
>
> I'm not sure to understand this. Syntactical things are all about
> context dependence in Org. Do you mean /context independance/ needs to
> be dealt with elsewhere?

No, I meant context of application, rather than context in the
syntactical sense.  Org-element-* deals with syntax, nothing else.
Whether you need strict syntactical interpretation or something else
gets decided someplace else.

> Could you provide examples about that? In particular "providing
> timestamps as arguments to any processing functions" sounds odd, in
> particular from someone who cringes when I suggest to add a second
> optional argument to a single function.

Whatever it sounds like, what you want in the clocktables example and
the properties example (and elsewhere) is something that looks, walks
and talks like a timestamp if you'd put it into the proper context.  In
each of these places the text that looks like timestamp but isn't
(org-element says so) will be fed into some machinery that emerges with
a result that is indistinguishable from what you'd get if that text
would have been a proper timestamp and then uses that result to do
whatever it wants to do with it (i.e. most certainly not build up an
agenda, although it could do that as well).  It uses a bit of Org syntax
in the improper context to achieve this (and this requires precisely to
ignore that context or at least check with something more loose than
org-element).

>> If I'd follow that road, I could edit what looks like a timestamp
>> everywhere, regardless of context.  I don't know if that's the right
>> thing to do and I don't even expect consensus among the Org user base.
>> I personally see no need to do that.
>
> I do see it, tho. This is analogous to links in comments. If you see
> something looking like a timestamp (or a link), you can expect some
> commands to operate on it. This is exactly what is biting us at the
> moment.

In a comment that timestamp-looking text doesn't have any function, so
it's in a different category, I must insist.  As I said, I can see
somebody wanting to have this text be editable like any other timestamp
also, but it's really the other uses where it's used meta-syntactically
that I'd like to focus on.  ONe of the differences to text in comments
(or generally quoted material) is that there is an expectation that this
sort of timestamp is correct, since they are intended to be input to
further processing.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs




Re: [O] More clocktable breakage

2017-05-01 Thread Achim Gratz
Nicolas Goaziou writes:
> Sadly, what a "timestamp" is depends on what function is asking. AFAICT,
> there are three categories of "timestamps".

Well, taking a further setp back, before Org started to have a formal
syntax anything that looked like a timestamp was treated as one.  The
different categories of timestamps really arise from the fact that we
now have syntactical timestamps and non-syntactical ones.  This in turn
requires that each function dealing with timestamps needs to specify
what exactly it wants to deal with, but as this discussion amply shows,
that isn't quite as straightforward as one would think.

> Let's consider the following examples:
>
>   (1)
>   SCHEDULED: <2017-04-30 dim.>
>
>   (2)
>   CLOCK: [2017-04-30 dim. 08:10]--[2017-04-30 dim. 08:11] =>  0:01
>
>   (3)
>   : <2017-04-30 dim.>
>
>   (4)
>   :PROPERTIES:
>   :DATE: <2017-04-30 dim.>
>   :END:
>
>   (5)
>   # <2017-04-30 dim.>
>
>   (6)
>
>   #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>"
>
> The first category is the "strict" one, which follows Org syntax
> definition. None of the examples above belong to that category.
> `org-element-context' should be the relative predicate, which means that
> it probably shouldn't return a timestamp object on planning lines, as it
> does at the moment.

I'd say anything org-element-* should exclusively return syntactical
things.  Context dependence needs to be dealt with elsewhere.

> The second category, which is a super-set of the previous one, is
> "agenda" one. Historically, Org allowed to insert timestamps in property
> drawers, e.g., as in (4), and use them in the agenda. So basically, this
> category contains "every timestamp that would appear as a plain
> timestamp in the agenda if it were active". `org-at-timestamp-p' is
> currently the relative predicate for that category. Note that the
> category also contains (2) if inactive timestamps are meant to be
> displayed in the agenda.

I would call that meta-syntax or maybe quoted syntax: you are looking at
a proper timestamp, to be used somewhere else where a timestamp is
needed, but in a context that doesn't specify a timestamp itself.  There
are many analogous cases elsewhere in Org, so it may be a fruitful
endeavour to consider this in a more general fashion.  Providing
timestamps as arguments to any processing functions (built into Org or
otherwise) carries the requirement that they should syntactically be
correct as a timestamp (so they can be converted into a timestamp object
at the place of use), so all functions to insert and edit a timestamp
need to work at those places.

> The last category, a super-set of the "agenda" one, is the "convenience"
> category. Basically, it contains every occurrence of what looks like
> a timestamp, but isn't necessarily one. Obviously, every example given
> above fits in there, as in every case, you can ignore that Org has
> a context-dependant grammar and pretend you are on a timestamp. There is
> no predicate relative to that category, but `org-at-timestamp-p'
> docstring suggests to use (org-in-regexp org-ts-regexp).

If I'd follow that road, I could edit what looks like a timestamp
everywhere, regardless of context.  I don't know if that's the right
thing to do and I don't even expect consensus among the Org user base.
I personally see no need to do that.

> So, about the predicates, I guess we could move the second one into
> "org-agenda.el" and rename it `org-agenda-at-timestamp-p'. However,
> using `org-at-timestamp-p' for the last category seems a bit
> far-stretched to me, since it doesn't always match timestamps. In
> particular, (3) and (5) sound counter-intuitive to me and I wouldn't
> like it from a developer standpoint. `org-at-timestamp' is also not
> really needed for the first category, since there is already
> `org-element-context'.

Agreed.  That's why I'm hesitant to change the org-at-timestamp-p to
(org-in-regexp org-ts-regexp) in the edit functions.  What I don't agree
with (if I've read you correctly) is the implied assertion that the
clocktable example is in the last category.  Or maybe it is at the
moment, but it ought to be in the second one.  I consider only examples
(3) and (5) to be in the "last" category.

> Yet, `org-at-timestamp-p' is something users are going to look after.
> Different names may also introduce confusion (remember `org-at-regexp-p'
> and `org-in-regexp-p'?). So, even if it looks like bad factoring to you,
> a single predicate, or even two if we set "agenda" apart, with
> a docstring explaining the different categories and how to select them
> may also be a good natural choice. Hence my suggestion.

Since org-at-timestamp-p already has an argument, adding a second one
doesn't look appealing to me, especially when the first one would often
be nil.  Maybe it's possible to change the definition of that argument
(which would need the equivalence between t meaning 'inactive).

> WDYT? Do you have any other concrete proposal?

I really only 

Re: [O] More clocktable breakage

2017-04-28 Thread Achim Gratz
Nicolas Goaziou writes:
> Another idea is to add an optional argument to `org-at-timestamp-p' to
> allow "sloppy" matching (or strict matching, it doesn't really matter)
> and skip checks when it is required. So all functions requiring this
> predicate can make use of it, as long as they call it properly.
>
> WDYT?

That's what I've been asking the whole time: when you changed that
predicate, you've basically cut off some of its consumers.  It looks
like bad factoring to me to then splitting the same predicate based on
some argument.  I'd rather pull out the old sloppy matching into a new
predicate for instance.

>> Also, again, I think that function is buggy even without these issues as
>> the only code I can find in org-element-context that deals with
>> timestamps is conditional on being on a planning line and if that's true
>> we should never get there.
>
> I don't think there is a bug there. Do you have an ECM?

I don't use planning, so no.  But it seems to me that the only way for
org-element-context to deliver a 'timestamp is when pos is on a planning
line (that may be wrong, I just don't see where else a 'timestamp would
be returned).  In that case we've already left the cond, so testing for it
doesn't do anything useful.  I'm also not really sure why the existing
exceptions from the "true" timestamp (planning, property and clock-log)
are any different than "dynamic block" would be (with the appropriate
change of the doc string of course).y


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves




Re: [O] More clocktable breakage

2017-04-27 Thread Achim Gratz
Nicolas Goaziou writes:

  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend 
 "<2006-08-10 Thu 12:00>"
  #+END: clocktable
>
> These are not timestamps. Even though they look like timestamps, you
> wouldn't want them to appear in the agenda. So `org-at-timestamp-p' is
> correct, IMO. Moreover, its docstring says
[…]

Well, that's the change you made that I pointed at earlier.  The
functionality of org-shift* has unfortunately regressed due to
that change you introduced by "hardening" the recognition of timestamps.
And no, to the user they really are timestamps in the arguments of a
dynamic block, splitting syntactical hairs aside.

> so ISTM a correct fix would be to have the function you're calling (I
> don't remember it) use this instead of `org-at-timestamp-p'.

I already said that the fix might not be the right one, although it
would be in the same spirit as the exceptions already present for
properties drawers, planning lines and clocks and org-at-block-p only
matches in the first line of a dynamic block, so I'd say it's still
sufficiently constrained.

N.B.: The regex used in org-at-block-p is overbroad since it matches the
whole block, I think it should use org-at-dblock-start-re instead.

Anyway, when you changed the scope of that function you'd need to check
all users of the API and fix them where necessary.  The main users of
that predicate were and still are the org-shift* family of commands and
they do expect a looser recognition than what you implemented based on
the docstring.  Maybe that's true in other places also, I haven't
checked.  It's also obvious that the test coverage of this is bad.  So
that looser recognition would need to be factored out again or you
revert this predicate and apply the stricter check where it matters (the
agenda functions, most likely).

Also, again, I think that function is buggy even without these issues as
the only code I can find in org-element-context that deals with
timestamps is conditional on being on a planning line and if that's true
we should never get there.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs




Re: [O] More clocktable breakage

2017-04-27 Thread Achim Gratz
Achim Gratz writes:
> Nicolas Goaziou writes:
>> At the moment, I cannot reproduce it. I tried M-up in the following
>> document:
>>
>>  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 
>> Thu 12:00>"
>>  #+END: clocktable
>
> The breakage happens in this clause in org-at-timestamp-p:
>
>(match
> (let ((boundaries (org-in-regexp tsr)))
>   (save-match-data
> (cond ((null boundaries) nil)
>   ((org-at-planning-p))
>   ((org-at-property-p))
>   ;; CLOCK lines only contain inactive time-stamps.
>   ((and inactive-ok (org-at-clock-log-p)))
>   (t
>(eq 'timestamp
>(save-excursion
>  (when (= pos (cdr boundaries)) (forward-char -1))
>  (org-element-type (org-element-context))
>
> After matching the timestamp in the header argument correctly, the code
> falls through to the default cond, where (org-element-type
> (org-element-context)) returns 'dynamic-block, which isn't a 'timestamp.
> The successful match gets discarded and the timestamp doesn't get
> recognized.  An empty clause for (org-at-block-p) would fix it, but I'm
> not sure that is the right thing to do.  I haven't looked at
> org-element-context to see whether it might misinterpret something.

I did look at org-element-context and the code in org-at-timstamp-p
makes even less sense to me now.  The only time org-element-context
returns 'timestamp is when it is on a planning line, but
org-at-timstamp-p has already left the cond in that case in the second
clause.


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: [O] More clocktable breakage

2017-04-26 Thread Achim Gratz
Nicolas Goaziou writes:
> At the moment, I cannot reproduce it. I tried M-up in the following
> document:
>
>  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 
> Thu 12:00>"
>  #+END: clocktable

The breakage happens in this clause in org-at-timestamp-p:

--8<---cut here---start->8---
 (match
  (let ((boundaries (org-in-regexp tsr)))
(save-match-data
  (cond ((null boundaries) nil)
((org-at-planning-p))
((org-at-property-p))
;; CLOCK lines only contain inactive time-stamps.
((and inactive-ok (org-at-clock-log-p)))
(t
 (eq 'timestamp
 (save-excursion
   (when (= pos (cdr boundaries)) (forward-char -1))
   (org-element-type (org-element-context))
--8<---cut here---end--->8---

After matching the timestamp in the header argument correctly, the code
falls through to the default cond, where (org-element-type
(org-element-context)) returns 'dynamic-block, which isn't a 'timestamp.
The successful match gets discarded and the timestamp doesn't get
recognized.  An empty clause for (org-at-block-p) would fix it, but I'm
not sure that is the right thing to do.  I haven't looked at
org-element-context to see whether it might misinterpret something.


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




[O] More clocktable breakage

2017-03-28 Thread Achim Gratz

I've just noticed that in my the clocktables at work I can't adjust the
start and end ranges anymore with up/down.  Apparently the timestamps
are not recognized anymore and the it falls through to some code that
tries to adjust the :block argument (which is not present in that table
since it's using :tstart / :tend) and fails with an error message.  I've
bisected that behaviour to commit 2a59d2f76f.  Unfortunately I can't
reproduce that here at home, maybe due to the fact that the language
settings are different.  At home the timestamps are recognized and the
clocktable is re-calculated accordingly.  However, I cannot refresh the
clocktable via C-c C-c, which tells me it cannot do anything useful at
that line.


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] Clocktable creates superfluous columns

2017-03-03 Thread Achim Gratz
Nicolas Goaziou writes:
> I'm a bit surprised that was the case. When fixing the clocktable,
> I also wondered what was the expected behaviour in that case, did some
> quick tests and came to the conclusion empty columns were fine.

I already said that I can see the utility of that in some cases, it's
just a user-visible change that I found not documented.

> Would you mind doing the bisecting part and providing an ECM?

I'll try to make some time for that.  OTOH, if it's just a matter of
implementing another customization option and code to pick up on that,
we may not even need to know when it changed.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] Clocktable creates superfluous columns

2017-03-02 Thread Achim Gratz
Nicolas Goaziou writes:
> Fixed. Thank you.

So the behaviour that whatever :maxlevel is set to becomes the number of
columns even when the rightmost columns are empty is now considered a
feature?  I haven't tried to bisect for when that changed, but empty
columns used to be dropped from the table.  I can see the new behaviour
useful sometimes, but the old one wasn't unreasonable either.  Is there
an option that I may have missed?


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] [ANN] New Org duration library

2017-02-21 Thread Achim Gratz
Nicolas Goaziou writes:
> You can post your old customization here, I try to help you convert it
> to the new format, if possible at all.

Well, once I remembered why I had to customize it, things fell into
place.  It wasn't something complicated, just that I wanted all
durations shown in h:mm, without days (for the timetable at work).

>> I'd first need to understand what the options there really mean.  It
>> seems that the variable can be set to just a symbol or (maybe) a string
>> or a list of conses.
>
> Strings are not allowed. It is either a symbol (h:mm:ss or h:mm) or
> a list of conses.

That sentence in the documentation would have helped.

>> I don't really see why you'd mix symbols and strings in the same
>> position.
>
> Probably because I couldn't find a better idea to cover all cases.

If units are defined as strings, then why can the format not be a string
also?  I still find this confusing, especially as there are multiple
other places in Org that use format strings quite happily.

>> I have no idea what "mixed mode" is supposed to be
>
> The definition of "mixed mode" is in the docstring:
>
>   When any of the first two is present, a duration is expressed in
>   mixed mode, where the hours and minutes of the duration are
>   expressed as a \"H:MM:SS\" or \"H:MM\" string while still using
>   other units defined.

Lost me right there again.  Please tell the user what problem he can
solve with this and then tell him how to do it, not the other way
around.  So, the purpose of this variable is to specify how you want
durations displayed in Org, using the predefined "special" formats or
user-defined org-duration units (there's a default on those as well).  A
duration format doesn't necessarily use all defined units, and of those
it is using it (always?) starts with the largest unit and ends with the
smallest.  This is the only one that can usefully have PRECISION, I
suppose, but the docstring shows there might be a possibility to chose
differently (I believe that means it ignores the smaller units in this
case).

> There is even an example in the docstring:
>
>   The following format
>
> ((\"d\" . nil) (special . h:mm))

Except the default really is shown as (("d") (special . h:mm)) if the
user cares to look things up.

>   means that any duration longer than a day is expressed with both
>   a \"d\" unit and a \"H:MM\" part, whereas a duration shorter than
>   a day is expressed only as a \"H:MM\" string.
>
> Basically,
>
>   1d 8:30
>
> is mixed mode.
>
>> and what happens if I specify both (special . h:mm) and ("h" . nil)
>> for instance. Is the order of these important?
>
> Specifying both (special . h:mm) and ("h" . nil) is nonsensical, since
> you request something like "0:30" in the first case, and "0h" in the
> second one.
>
> In this case, I think ("h" . nil) is going to be ignored since (special
> . h:mm) already takes care of hours an minutes.

I've picked something that I expected to be nonsensical on purpose,
although I think it wouldn't be entirely unreasonable for a user to
expect that the duration would simply get formatted both ways.  The
documentation should tell me not to do that or if it's ignoring part of
the specification.  I take from your answer that the order of
specification might not be important, but it's not spelled out in the
docstring yet.


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: [O] [ANN] New Org duration library

2017-02-21 Thread Achim Gratz
Nicolas Goaziou writes:
>> You seem to have (some of) these aliased to org-duration format somehow.
>> This breaks a lot of things because the format of the former variables
>> is not recognized.  I got a bunch of errors about :hour not being a list
>> for instance.  There surely must be a better way to handle the
>> transition?
>
> Fixed. Thank you.

Thanks, but will there be some helper function to migrate the old
customizations?  I didn't even remember that I had customized this
variable until I couldn't clock in or out anymore (I remember now that I
customized it so it would record durations in hours, not days/hours).

>> Also, I find the documentation to be completely impenetrable.
>
> Great. Suggestions welcome.

I'd first need to understand what the options there really mean.  It
seems that the variable can be set to just a symbol or (maybe) a string
or a list of conses.  The conses form refer to org-duration-units, but
there the units are all defined as strings and no mention of the symbol
special that apparently is another possibility.  I don't really see why
you'd mix symbols and strings in the same position.  I have no idea what
"mixed mode" is supposed to be and what happens if I specify both
(special . h:mm) and ("h" . nil) for instance.  Is the order of these
important?

>> Customization has offered to create a setting for org-duration-format
>> that's not even mentioned in the documentation.
>
> Would it be possible, by any chance, to get a glimpse of that setting?

I've set it to the symbol h:mm (shown as H:MM in customize) via the
value menu in customize.  I might read the documentation incorrectly,
but to me it seems to say it should be the string "h:mm" instead.  I'm
left to wonder if (h:mm) is the same or different from ((special . h.mm)).


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: [O] [ANN] New Org duration library

2017-02-21 Thread Achim Gratz
Nicolas Goaziou writes:
> `org-time-clocksum-format', `org-time-clocksum-use-fractional' and
> `org-time-clocksum-fractional-format' are obsolete. If you changed them,
> consider modifying ~org-duration-format~ instead.

You seem to have (some of) these aliased to org-duration format somehow.
This breaks a lot of things because the format of the former variables
is not recognized.  I got a bunch of errors about :hour not being a list
for instance.  There surely must be a better way to handle the
transition?

Also, I find the documentation to be completely impenetrable.
Customization has offered to create a setting for org-duration-format
that's not even mentioned in the documentation.

Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] org manual not updating when pulling from git

2017-02-08 Thread Achim Gratz
Marco Wahl writes:
> Ah!  I didn't see target 'compile-dirty'.  Thank you for the hint.
>
> So for now I'm happy with the build process with the existence of
>
> make compile-dirty
>
> and further
>
> make test-dirty
>
> Also the names are well chosen AFAICT.
>
> I agree that the commit should be reverted and I already did the revert.
> Please accept my apology for the irritation about the build behavior.

No problem.  But in the future, please ask here first if you think you
find something in the build system that you can optimize.  Maybe it was
an oversight or it's a workaround that has become obsolete, but usually
there's an actual reason behind.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] org manual not updating when pulling from git

2017-02-07 Thread Achim Gratz
Nick Dokos writes:
> "make doc" or "make pdf" will update the PDF file. If you use one of
> the update targets in the makefile, it may have been updating the pdf
> doc under the covers. Taking a look through recent commits, the only one
> that might be relevant seems to be this:
>
> ,
> | commit c90c7a33f53ad88dfcc583ad4c77bec306da0b22
> | Author: Marco Wahl 
> | Date:   Wed Feb 1 11:16:16 2017 +0100
> | 
> | targets.mk: Drop the rule to clean at every compile
> | 
> | Rationale: 1. Save time and energy.  2. Use the make tool for what
> | it's been made.
> `

That commit should probably be reverted.  The make tool can't do what
it's been made for in this case since some of the dependencies can not
be correctly determined.  You can still skip the clean if you want to by
using the compile-dirty target.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves




Re: [O] I have org-plus-contrib from ELPA. How do I temporarily test Org from git?

2017-02-04 Thread Achim Gratz
Kyle Meyer writes:
>> As a precaution, I have uninstalled ELPA org-plus-contrib before
>> ‘sudo make install’.  After testing, I installed ELPA org-plus-contrib
>> again.  Was that really necessary?
>
> No, you can use "emacs -q" to avoid loading your main init file.

That still loads the site init files.  Besides, he might need something
else from ELPA for testing, so just starting up a bare-bones Emacs might
not be very helpful either.


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] speeding up Babel Gnuplot

2017-01-04 Thread Achim Gratz
Thierry Banel writes:
> There is no way to ensure a single call to
> (org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't
> want to do that because I would have to change a lot of babel backends.

But that is the right fix to apply, unless there is a reason for the
input vars to be processed multiple times.  I haven't looked at the
Babel code in the last two years, but generally I'd suggest that each
argument should only be processed once per Babel block since the second
processing could have unwanted side-effects.


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] Proper git settings to stay with master?

2016-12-24 Thread Achim Gratz

Am 23.12.2016 um 20:49 schrieb John Hendy:

Sure... I get that that I *can* do that. I just wondered why I
*needed* to do that.


When you are in a "detached HEAD" situation, you will always have to 
tell git explicitly to switch to some other commit (most likely a 
branch).  Git pull works with branch heads, but you've not checked out 
any, so it won't do anything and can't, since it will potentially lose 
data if it tried.



This makes sense. I don't know why this never happened before, but
checking out a specific commit makes sense.


Checking out a specific commit not at the branch head, to be precise.

> Perhaps I was bisecting

something in the past and checking out various commits? Once you check
out *something*, do you always have to re-checkout something else to
undo this effect (and make it like the default)? As in if I check out
a commit and then =git pull=, it won't go back to master?


Git status tells you where you've currently checked out.


--
Achim.

(on the road :-)




Re: [O] Proper git settings to stay with master?

2016-12-23 Thread Achim Gratz

Am 22.12.2016 um 17:44 schrieb John Hendy:

$ git pull
From http://orgmode.org/org-mode
   13751c3249..820d1eb617  maint  -> origin/maint
   7fd61c4f92..1c89082600  master -> origin/master
You are not currently on a branch.


Well, then you want to do a

git checkout master

or

git checkout maint

depending on which branch you want to be on.


Have I botched something? If so, what would be the method to remedy?
If not, what should be updated in the instructions regarding sticking
with master? I see references on how to specify maint, but that seems
to imply that master is the default and action is only required to
override to use maint branch.


Master _is_ the default, so you must have specifically checked out a 
commit not at the branch HEAD or left a bisect or similar command that 
replays history hanging unfinished somewhere.


--
Achim.

(on the road :-)




Re: [O] Remove Org from Emacs repository?

2016-12-19 Thread Achim Gratz
Phillip Lord writes:
> I think there's only a few problems, actually. package.el initialization
> is all or nothing at the moment, and is disabled on emacs -q. Neither of
> these would make sense if we wanted in built packages.

My opinion is that unless package.el adds explicit support for
system-level packetization decisions (i.e. for admins or distributions)
it's not going to gain widespread support from that small, but important
set of folks.  Of course the user will then have to be able to override
these like deactivation of packages, installing different versions, etc.
Before long it also needs to be able to cope with different package
archives simultaneously especially when those have incompatible
numbering schemes.

> It's not strictly necessary, though. The current idea is to not to use
> packages but to, essentially, move the lisp of packages in ELPA into
> place in the build. package.el need not be involved then.

Yes I know.  Which is in essence prolonging the current state of affairs
as far as the users are concerned.  If it gets things moving into the
right direction I'll be glad.  I just had hoped for some more general
(some would say radical) solution.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves




Re: [O] Remove Org from Emacs repository?

2016-12-19 Thread Achim Gratz
Reuben Thomas writes:
> ​Org is nearly 90kLOC, or about 6.5% of the total ELisp code currently in
> Emacs. It's bigger than CEDET, smaller than GNUS.

Within the whole of Emacs, an argument about size doesn't make any sense
at all.  It's also quite arbitrary, as some functionality that comes
with Org could or even should be factored out into their own packages
eventually.

> It's a project of its own with its own release cadence. It would be good to
> make Emacs less of a monolithic entity, which needs lengthy debugging
> cycles between releases, and has to choose between being out of date with
> various upstreams, or delaying to test integration of big packages.

That needs to be discussed with Emacs devs, not Org (or any other
package that fits a similar profile).  And it has been discussed in the
past, with somewhat interesting responses on both sides.

> Now that package.el is mature, there's no need for Emacs to include all
> this stuff in its source releases.

That assertion isn't universally accepted as true.  Org in particular
continues to show how the integration into Emacs as well as some
functionality in package.el itself is still lacking.  True packetization
of Emacs' "built-in" packages is further hindered by the fact that
package.el is currently solely "user-centric" and lacks the usual
facilities for curating package selection at the installation level.

> ​No, I was just testing the waters to see if a more modern approach to
> development and distribution might be popular. Apparently the answer is, at
> least, not yet!

Again, that's ultimately something for GNU Emacs to decide upon.  But it
doesn't come free nor is all the necessary infrastructure in place yet.


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: [O] Release 9.0 test failed: test-ob/indented-cached-org-bracket-link

2016-11-19 Thread Achim Gratz
Charles C. Berry writes:
> Doing this with `make test', I see that default-directory is let bound to
>
> "/var/folders/kb/2hchpbyj7lb6z76l0q73w_fhgn/T//tmp-orgtest/"
>
> and (concat default-directory "test.txt") will retain the double slash.

Not to sound facetious, but it seems that the make variable testdir gets
set to a path that has a trailing slash.  Fix that and the problem
should go away (most likely TMPDIR has a trailing slash).  Check with

: make config

or even

: make config-all

that the variable is set correctly.

Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: [O] Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

2016-11-01 Thread Achim Gratz
Nicolas Goaziou writes:
> This is not what I'm suggesting. Let me try to expunge a bit.
>
> I thing we should automate bugfix releases with regular version
> numbering scheme, e.g., 8.3.7 release, /as a replacement for/
> org-MMDD releases. Therefore:

No, we shouldn't.  It's either automatic or a release, it can't be both.
Also, the releases are distinct from the ELPA packages and you seem to
mix up the two.  They are not the same thing.

> 1. org-MMDD could be renamed org-MAJOR-MINOR-BUGFIX# where MAJOR
>MINOR are never modified automatically, and BUGFIX# is (1+ last
>BUGFIX#).

Org's ELPA package has its own versioning scheme and unless package.el
grows some functionality to sanely deal with discontinuities in
versioning, we need to stick to it.

> 2. Conditions to make a new automated release ought to change. We could
>wait for a full "idle" week after a commit before releasing (IOW,
>wait for one week after a commit but every new commit during that
>period resets the counter). "next Monday" rule has bitten us already.
>The new rule is not perfect either, but is more secure. If one full
>week is too long, we may reduce it to 4 days.

Again, if you talk about releases, the way to do that is to tag what
should be released, preferrably sign the tag as well.  Whether you roll
the release automatically or script up somthing that picks up new tags
and does it for you is a separate issue.

BTW, if the Monday ELPA package is bad you can always trigger another
release to ELPA manually and don't need to wait for next Monday to have
cron run the release script.


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] Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

2016-10-31 Thread Achim Gratz
Nicolas Goaziou writes:
> However, I think we should make more frequent bugfix releases. We may
> even automate such releases, e.g., one week after the last unreleased
> bugfix in the branch. I don't do releases however, so this may just be
> a weird idea.

We already have that, it's the Org package on GNU ELPA.  There's a new
release each monday, fully automated.

> Also, I'd rather have monotonic version tags, so 8.3.6.whatever is not
> really an option. Maybe 8.3.YYYMMDD... and we drop manual bugfix
> releases altogether.

No, the reason for versioning Org on ELPA in that way is how package.el
interprets version numbers.  You'll get a version string you can
correlate to the Git repo from org-version.


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: [O] Time to push the latest org to emacs-25 branch?

2016-09-18 Thread Achim Gratz
Nicolas Goaziou writes:
> Besides, I don't know what is the status of Org wrt Emacs, since some
> packages are going to be moved outside of Emacs core for development and
> bundled with Emacs only at the time of release.

My understanding of this discussion is that this will not happen for
Emacs 25.x.  Master is going to feed into Emacs 26, while the Emacs 25
branch stays open for bugfixes that didn't make it into 25.1, for a
possibly quick(er) release of 25.2.


Regards
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves




Re: [O] Org links, URLs and HTML export

2016-08-23 Thread Achim Gratz
Fabrice Popineau writes:
> I can insert : [[http:bar.html]]
> However, I would like to be able to insert any kind of relative url.
> Specifically, there is no mean to insert something
> like : [[http:/bar.html]] which is exported to 
> The corresponding export should be 

But that's an absolute URL, provided a well-defined base URI exists (the
authority is implied and the path component starts with a slash, so it
would start in the root).

> Strangely, some browsers grok the former (Chrome), but not all of them
> (Safari).

Then Safari either has a bug or it determines the base URI differently
than Chrome.

> Anyway, only the later is correct.

I don't think so.  You might want to read

https://tools.ietf.org/html/rfc3986

specifically the part about the translation of relative URI.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




[O] ob-sed-test failure introduced by f38f83b4

2016-07-11 Thread Achim Gratz

Two of the three ob-sed tests are failing after commit f38f83b4, but
only in batch mode.  It seems the final newline gets eaten somewhere,
leading to the string= howling in protest.  When I run the code in
question interactively, it works as expected (result shown in minibuffer
is a string _with_ the final newline).  I can't figure out why the
particular commit is having that effect, but it seems to have changed
some accidental setting that the sed tests were relying on.

--8<---cut here---start->8---
Test ob-sed-test/in-file-header-argument condition:
(ert-test-failed
 ((should
   (string= "A tested file.
"
(org-babel-execute-src-block)))
  :form
  (string= "A tested file.
" "A tested file.")
  :value nil))
   FAILED  2/3  ob-sed-test/in-file-header-argument
--8<---cut here---end--->8---

--8<---cut here---start->8---
Test ob-sed-test/simple-execution-of-script condition:
(ert-test-failed
 ((should
   (string= "A processed sentence.
"
(org-babel-execute-src-block)))
  :form
  (string= "A processed sentence.
" "A processed sentence.")
  :value nil))
   FAILED  3/3  ob-sed-test/simple-execution-of-script
--8<---cut here---end--->8---


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] Why no secure code retrieval

2016-07-03 Thread Achim Gratz
Konstantin Kliakhandler writes:
> For what it is worth, the current discussion is actually precisely what I
> was aiming at. I agree with your analysis of my Intended goals but
> completely disagree that SHA1 alone is any sort of guarantee.. To be
> precise, I don't just think that it doesn't provide much, but rather that
> alone it provides none at all. This is because I have no idea who produced
> a given SHA1 - whether it was Bastien, or a MITM attacker, or just someone
> who compromised the server.

Getting the same data via https doesn't give you that sort of guarantee
either, it only ensures that the data cannot be read and altered in
transport.  If the server or repo gets compromised, then it is game over
until someone notices that the server suddenly doesn't match up the
local clone.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs




Re: [O] Why no secure code retrieval

2016-07-03 Thread Achim Gratz
Bastien Guerry writes:
> I encourage you to try gogs, it is very easy to install and maintain,
> and its interface is very engaging.  The more gogs users and potential
> admins out there, the more comfortable I'll feel making the switch.

If it requires anything more than dropping in the public SSH keys for
enabling contributors, then that's a no-go IMHO (and any other candidate
that'd share this characteristic).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves




Re: [O] Provide rsync access to Org ELPA

2016-07-02 Thread Achim Gratz
Chunyang Xu writes:
> rsync access would allow people to efficiently mirror Org ELPA
> [http://orgmode.org/elpa/]. Please provide rsync access to it.

Git transport is more efficient than rsync.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves




Re: [O] How to contribute?

2016-06-08 Thread Achim Gratz
aermo...@mirantis.com writes:
> I'm also thinking of contributing to orgmode, so my question is - is
> there any publicly available contributing guide, being SPOT for
> newcomers?

http://orgmode.org/worg/org-contribute.html

If you think anything is missing or needs better explanation, make that
your first contribution!


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] Bug: Smart quotes for LaTeX export broken in tables [8.3.4 (8.3.4-9-gfda14f-elpa @ elpa/org-20160307/)]

2016-03-13 Thread Achim Gratz
Nicolas Goaziou writes:
> Unfortunately, I cannot reproduce the failure. Neither can our buildbot.
> Could you investigate a bit more about it?  For example, how is the
> document below exported to ASCII?
>
>   #+options: ':t
>   #+language: en
>
>   *"test"*

--8<---cut here---start->8---
Table of Contents   

   
_   

   


   


   


   


   
*"test"*

   


   
Org-mode version 8.3.4 (release_8.3.4-15-gdd9be3 @  

   
/usr/share/emacs/site-lisp/org/)

   
--8<---cut here---end--->8---


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] Bug: Smart quotes for LaTeX export broken in tables [8.3.4 (8.3.4-9-gfda14f-elpa @ elpa/org-20160307/)]

2016-03-13 Thread Achim Gratz
Nicolas Goaziou writes:
> Fixed. Thank you.

This might have fixed the functionality, but the test you introduced
fails on Emacs 24.4 on Raspbian/Jessie:

--8<---cut here---start->8---
Test test-org-export/activate-smart-quotes backtrace:
  (if (unwind-protect (setq value-99840 (apply fn-99838 args-99839)) (
  (let (form-description-99842) (if (unwind-protect (setq value-99840 
  (let ((value-99840 (quote ert-form-evaluation-aborted-99841))) (let 
  (let ((fn-99838 (function equal)) (args-99839 (list (quote ("
  (lambda nil (let ((fn-99763 (function equal)) (args-99764 (list (quo
  #[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\317\320%DC
  funcall(#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316\"\31
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  #[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\316%DC\2
  funcall(#[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314\"\315\
  ert-run-test([cl-struct-ert-test test-org-export/activate-smart-quot
  ert-run-or-rerun-test([cl-struct-ert--stats "\\(org\\|ob\\)" [[cl-st
  ert-run-tests("\\(org\\|ob\\)" #[385 "\306\307\"\203D\211\211G\310
  ert-run-tests-batch("\\(org\\|ob\\)")
  ert-run-tests-batch-and-exit("\\(org\\|ob\\)")
  (let ((org-id-track-globally t) (org-test-selector (if org-test-sele
  org-test-run-batch-tests("\\(org\\|ob\\)")
  eval((org-test-run-batch-tests org-test-select-re))
  command-line-1(("--eval" "(setq vc-handled-backends nil org-startup-
  command-line()
  normal-top-level()
Test test-org-export/activate-smart-quotes condition:
(ert-test-failed
 ((should
   (equal '...
(let ... ...)))
  :form
  (equal
   ("foo")
   (#("*foo*" 0 1 ... 8 11 ... 18 19 ...)))
  :value nil :explanation
  (list-elt 0
(arrays-of-different-length 17 19 "foo"
#("*foo*" 0 1 ... 8 
11 ... 18 19 ...)
first-mismatch-at 0
--8<---cut here---end--->8---


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] Precision in the spreadsheet

2016-03-01 Thread Achim Gratz
Nick Dokos writes:
> Marcin Borkowski  writes:
>> is it at all possible to set different precision for display and
>> calculations in Org's spreadsheet?  I mean, things like $1+$2;%.2f (as
>> in the manual) mean (IIUC) that (1) Org should show 2 decimal figures
>> and (2) further calculations which use this value also use this
>> approximation.  Am I right?  If yes, is there a way to change this
>> behavior?  (I suspect not, but I wanted to make sure.)

I guess everything is somehow possible, but it either requires to store
the data with full precision somewhere or re-calculate the table with
full precision each time and only then apply the display rounding.  I've
had this idea for some time that tables should have a shadow that
determines formatting and other behaviour, there should probably be a
way to keep raw data in the shadow as well.  Meanwhile you could
experiment with putting the data in a table somewhere with full
precision and use Babel to display that data somewhere else the way you
want it.  If you wanted to be able to edit some data in that second
table it would be more bothersome.

> I believe that internally, calculations are done in 12-decimal place
> precision: the %.2f is for display only.

Sure, but as far as org-table is concerned, the data that is displayed
is the data that gets used:

* Table precision
|  1 | 0.00 |  0. |
|  2 | 0.00 |  0. |
|  3 | 0.00 |  0. |
|  4 | 0.00 |  0. |
|  5 | 0.01 | 10. |
|  6 | 0.01 | 10. |
|  7 | 0.01 | 10. |
|  8 | 0.01 | 10. |
|  9 | 0.01 | 10. |
| 10 | 0.01 | 10. |
| 11 | 0.01 | 10. |
| 12 | 0.01 | 10. |
| 13 | 0.01 | 10. |
| 14 | 0.01 | 10. |
| 15 | 0.01 | 10. |
#+TBLFM: $2=$1/1000;%.2f::$3=1000*$2

When calculating the third column, the formula to calculate the second
column doesn get re-evaluated to regain the precision lost while
displaying it.  Org also doesn't keep shadow data and computes the
display on the fly like most other spreadsheets do.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] Is it possible to keep /all/ the heading properties in one place?

2016-02-29 Thread Achim Gratz
Thomas S. Dye writes:
> The project had a mixed reception and ultimately wasn't adopted, but I
> don't remember Texinfo exporter deficiencies figuring into the
> decision.

Well, maybe except that the texinfo exporter is even slower than
texinfo5.  I haven't tried it in the last few months, but I expect that
the makefile integration still wokrs, even though the manual is now out
of date… nope, there's an error now:

--8<---cut here---start->8---
Invalid search bound (wrong side of point)
Makefile:39: recipe for target 'orgmanual.html' failed
--8<---cut here---end--->8---

So it needs some love and at least one bugfix.


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] [PATCH] org-attach: Fix git annex test directories

2016-02-16 Thread Achim Gratz
Erik Hetzner writes:
> Thanks for bearing with me on getting git-annex to work properly. This fixes 
> an
> issue with running tests on debian with older versions of git-annex.

Pushed to 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: [O] Invalid function: org-babel-header-args-safe-fn in Melpa

2016-02-14 Thread Achim Gratz
Aaron Ecay writes:
> This looks like the kind of problem that results when org is byte-compiled
> in an emacs with a different version of org loaded.  This used to be a
> problem when installing via package.el (and not just for org), but I think
> there has been some work put into making sure it doesn’t happen any more.
> (I know emacs developers were discussing them and then they seemed to go
> away so I assumed they were fixed...it’s possible I was mistaken though.)

No, this is bug #10125 and the others that it was merged with (most
recently #21267, with the exact same error message as John got).

> If I had to guess, I’d say that line 63 of packages.el in your jmax
> setup defeats these fixes.  Try commenting it out.  It should not be
> necessary to manually byte-compile packages: package.el should do that
> for you.  And in this case, I hypothesize that it is actually harmful.

Yes it is.  Although I'd venture to guess that it would have happened
anyway.


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] Invalid function: org-babel-header-args-safe-fn in Melpa

2016-02-14 Thread Achim Gratz
John Kitchin writes:
> I am trying to debug an issue with installing org-mode from Melpa.

There's no Org on Melpa or at least there shouldn't be.

> After installing org from Melpa, I get this on starting emacs:
>
> byte-code: Invalid function: org-babel-header-args-safe-fn

You must not install Org while it has already been loaded (i.e. since
your startup files alkmost certainly reference it somewhere you'll have
to do it from emacs -Q) and you must not use anything from Org in your
startup files before package-initialize has been done.


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: [O] [PATCH] testing/lisp/test-org-attach-annex.el: New file

2016-02-14 Thread Achim Gratz
Erik Hetzner writes:
> * testing/lisp/test-org-attach-annex.el: Move all org-attach tests that
>   use git-annex to this file, which can test for the presence of
>   git-annex. Prevents tests failing on systems where git-annex is not
>   installed.

Thanks, pushed with a slight edit of the commit summary.  I've added the
Makefile enhancements in a separate commit.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




Re: [O] [PATCH] org-attach.el: Get attachments from git annex

2016-02-11 Thread Achim Gratz
Erik Hetzner writes:
> Can you explain how this improves on what I had? The time spent appears to be
> the same on my system (tested after clearing the filesystem cache):

For users that are not using git-annex, it's doing exactly the same
thing as before.  The rest kicks in as long as git-annex keeps its
"lockdown" feature.  Lastly, systems that might not have a chown can
substitute a replacement.  I don't care about the time at all.

> git-annex version: 5.20150731-1build1. In any case, direct mode is a rather
> different use case, as I understand it.

The question was if it would allow the tests to succeed without this
extra nuisance of having to chown the git repo afterwards.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs




Re: [O] [PATCH] org-attach.el: Get attachments from git annex

2016-02-09 Thread Achim Gratz
Erik Hetzner writes:
> Sorry - I misunderstood how `org-test-for-executable' works. I’ll fix the 
> issue.

Thanks.

> As for the rm -rf, it does not work in the way you suggest, at least on ubuntu
> GNU/Linux. Here is the result I get locally without the chmod:

For pete's sake, what are the permissions?  As I said, the only reason I
see that is happening is if the directory containing the files is mode
55x.  And that would either be spectactularly stupid or exceptionally
clever, although I tend toward the first interpretation.  In any case,
you'd need to make the directories writable to fix this, but not the
files.  There might be a config option that you could/should set to
avoid this bit of cleverness or nuisance by git-annex..


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] [PATCH] org-attach.el: Get attachments from git annex

2016-02-09 Thread Achim Gratz
Erik Hetzner writes:
> Here are the permissions:
>
> 0755 /tmp/tmp-orgtest/
> 0700 /tmp/tmp-orgtest/org-annex-test19785b6F/
> 0775 /tmp/tmp-orgtest/org-annex-test19785b6F/.git/
> 0775 /tmp/tmp-orgtest/org-annex-test19785b6F/.git/annex/
> 0775 /tmp/tmp-orgtest/org-annex-test19785b6F/.git/annex/objects/
> 0775 /tmp/tmp-orgtest/org-annex-test19785b6F/.git/annex/objects/jm/
> 0775 /tmp/tmp-orgtest/org-annex-test19785b6F/.git/annex/objects/jm/P2/
> 0555 
> /tmp/tmp-orgtest/org-annex-test19785b6F/.git/annex/objects/jm/P2/SHA256E-s12--a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447/
> 0444
> /tmp/tmp-orgtest/org-annex-test19785b6F/.git/annex/objects/jm/P2/SHA256E-s12--a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447/SHA256E-s12--a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447
>
> I presume this is to maintain the integrity of the file contents in the
> repository.

Oh my, they even think it's a feature.  :-(

https://git-annex.branchable.com/internals/lockdown/

Those shenanigans with symbolic links are a bit cumbersome.

> It would be possible to drop these files after the test (using git annex drop
> --force), but if something goes wrong there the rm -rf would not clean up the
> test directory properly. If you think that is a better solution I can do that.

Well, the best solution would be to have an option for git-annex to
switch off that lockdown thing.  Since that's not going to happen soon
or anytime, try something like:

$(RMR) $(testdir) || { $(CHMOD) -R u+w $(testdir); $(RMR) $(testdir) }

which of course requires the addition of

CHMOD = chmod

in mk/defaults.mk.

But it seems that direct mode (however deprecated it is) would allow us
to do exactly the thing we want, so maybe if the tests would put that
repo in direct mode we wouldn't even need to do that.  But that doesn't
seem to work in a v6 repo unless annex.thin is set to true.  What version
are you testing?


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] org-attach.el: Get attachments from git annex

2016-02-07 Thread Achim Gratz
Erik Hetzner writes:
> Thank you for all your feedback on this code! I’m really happy with how it
> turned out, and glad it is in master now.

Please fix the tests to not fail (preferrably not run) if git-annex is
not installed.

Also, revert the patch to mk/targets.mk; $(RMR) already includes the
'--force' flag, so it can remove write protected files just fine.  If
it's write protecting directories then that would be stupid, but still
no reason to chmod all files.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] make test hangs (master)

2016-02-02 Thread Achim Gratz
Erik Hetzner writes:
> It turns out the issue is my prompt, that is, the value of the =PS1= 
> environment
> variable, which contains a lambda (λ, U+03BB). I suspect the following will 
> fail
> for all:
>
>   $ PS1="λ " emacs -Q --batch -L lisp/ -L testing/ -L testing/lisp -l 
> lisp/org.el -l lisp/org-id.el -l testing/org-test.el --eval "(progn 
> (org-reload) (setq org-confirm-babel-evaluate nil) 
> (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . t) 
> (shell . t) (org . t" -f org-test-run-batch-tests
>   …
>  passed   70/443  test-ob-shell/dont-insert-spaces-on-expanded-bodies
>   [ hangs here ]

FWIW, I can't reproduce it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] Bug: Export breaks on documents with title [8.3.3 (8.3.3-26-ge92a06-elpaplus @ /Users/leafac/.emacs.d/elpa/org-plus-contrib-20160125/)]

2016-01-28 Thread Achim Gratz
Leandro Facchinetti writes:
> I was able to figure out the issue: my versions of the packages `org'
> and `org-plus-contrib' were not matching. Updating both solved the
> issue.

In fact you should only have one or the other package installed, not
both.  I some other package tries to pull in org while you want to have
org-plus-contrib, then you need to drop a dummy org package so that ELPA
doesn't pull in a second installation.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] Org-mode via ELPA and via git in parallel

2016-01-28 Thread Achim Gratz
Karl Voit writes:
> As I noticed yesterday, in my ELPA-directory there is
> "org-20160125/" which I never installed on purpose.

It's probably been pulled in by some dependency.  Package manager is not
very smart with this.  You need to drop a dummy org package with a high
enough version so that Org never gets upgraded via package manager.

> 1. Do I have to care about the ELPA Org-mode folder (ignoring the
> occupied disk space) or might this ELPA Org-mode interfere with my
> git Org-mode?

No, you shouldn't have it installed via ELPA.  It may work one day and
stop working another depending on which patch your initializations
actually take.

> 2. How am I able to find out why the ELPA Org-mode folder exists in
> my setup?

Some other package pulls it in as a dependency.  Package manager
operates on the assumption that you install everything via ELPA.  If you
don't, then you have to take care of that yourself.


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] commit 7b9f2fba66

2016-01-26 Thread Achim Gratz
Rafael Laboissiere writes:
> I am the author of the commits and I sincerely apologize for breaking
> the usual rules of development of Org-mode.

Thanks.

> I contributed in the past to both Worg and Org-mode itself.  I do not
> remember who gave me push access to the Git repositories, it was some
> years ago.  I have forgotten that all my contributions and patches to
> Org-mode where integrated by others into Git.  This time, when I fixed
> the bugs in my commits 860bcfb and 7b9f2fb, I thought that I have
> pushed changes in the past myself.  Sorry for the confusion.

It's quite likely you were supposed to have access to Worg.  That
shouldn't give you commit access to the Org repository however.  So I'd
still would like to know how you've gotten the latter part, since this
seems to indicate some oversight somewhere.  Somebody with access to the
server config should at least check that all people with permission to
commit have assigned copyright to the FSF, IMHO.

> As a matter of fact, none of those two commits introduced changes in
> functionality.

Thanks.  If you commit something to maint, you're supposed to merge that
bugfix back into master yourself.

> Nicolas Goaziou contacted me privately and suggested to get the
> copyright assignment from FSF.  I am about to sent the form to them
> and will keep you informed when it is finished.  In the meanwhile, I
> will send my patches to the ML, if there will be any.

Getting the copyright assigned would be good since if you've had some
previous changes (not the two commits you did yourself), then quite
likely you've already exhausted your TINYCHANGE budget.


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




[O] commit 7b9f2fba66 (was: commit 860bcfbf93)

2016-01-25 Thread Achim Gratz
Achim Gratz writes:
> This commit is marked as TINYCHANGE, but committed by the author
> himself.  How and why did someone not having assigned copyright to the
> FSF get push access to the Orgmode repository?

The same thing again, with no previous communication on the mailing list
and again on maint without a clear indication of whether that's
changing functionality.

Again, who gave this person the commit bit?


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




[O] [Bug] Testing: ESS (*R*, R (newest)) starting data directory?

2016-01-24 Thread Achim Gratz

This is probably caused by an update of ESS rather than some change in
Org, however Org should probably bind ess-ask-for-ess-directory to nil
during batch testing at least.  There may be other customizations that
need to be taken care of, I also get

Cannot read history file […]/org-mode/testing/examples/.Rhistory

in the testing output.  Someone who actually uses ESS on a regular basis
needs to decide the appropriate course.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




[O] commit 860bcfbf93

2016-01-24 Thread Achim Gratz

This commit is marked as TINYCHANGE, but committed by the author
himself.  How and why did someone not having assigned copyright to the
FSF get push access to the Orgmode repository?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




Re: [O] [Bug] Testing: ESS (*R*, R (newest)) starting data directory?

2016-01-24 Thread Achim Gratz
Charles C. Berry writes:
> Nope. I failed to let bind ess-ask-for-ess-directory in adding a test
> a few days ago.
>
> Fixed in commit 27b590c39551f9aae79d801f61125cbaf1bd896c.
[…]
> Now fixed by binding `ess-history-file' to nil.


Thank you.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




Re: [O] Losing trust in Org: stable org-mode releases and unit tests for basic functionality

2016-01-17 Thread Achim Gratz
Karl Voit writes:
> I had several occasions where "git pull origin master" ended up in
> much work for fixing my large set of Org-mode data. 

That's the development branch which can introduce new features and
remove old ones at any time, you should be on maint if you want
"stable".  If you want even more stable, then don't update unless you
hit a bug that is fixed in maint.

> What I am trying to raise is a discussion on whether or not there
> should be a stable git branch or at east some kind of unit test set
> that make sure that really basic functionality doesn't get broken
> without being recognized instantly. In my humble opinion, there has
> to be some kind of continuous integration tests where breaking
> things rings loud whistles.

There already is, it's called "maint".  And if any tests fail on your
machine, then the convenience target "up2" doesn't install the resulting
Org, so you never see that broken version.

> Unfortunately, I don't have time to follow all the interesting
> discussions on the mailing list any more. Does this imply, I can't
> use Org-mode any more?

No, but I'd say you shouldn't use the development version of Org and you
shouldn't run Org directly from the Git worktree.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: [O] Bug: #+begin_html.. #+end_html export bugs [8.3beta (release_8.3beta-1038-gcd7cbd @ d:/ZballInstall/EZWinSoft/msys64/mingw64/home/github/org-mode/lisp/)]

2016-01-06 Thread Achim Gratz
tyuuni writes:
> Package: Org-mode version 8.3beta (release_8.3beta-1038-gcd7cbd @ 
> d:/ZballInstall/EZWinSoft/msys64/mingw64/home/github/org-mode/lisp/)

You are using an outdated version of Org.  Please update and check if
the bug wasn't already fixed.


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: [O] Proposal and RFC for improving ob-python

2015-12-07 Thread Achim Gratz
Ondřej Grover writes:
> If this list is not appropriate for discussion of improvements to
> ob-python.el, could you please give me pointers how to reach people that
> might be interested in helping and discussing?

The best way to contribute to improving ob-python is by showing a patch
that implements your ideas and still passes all existing tests.  Bonus
points if you add new tests for better coverage or any new functionality
or improvements.


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] Allowing loose ordering in Org files

2015-11-10 Thread Achim Gratz
John Wiegley writes:
> If the answer from the maintainers is "It's more work than we want to do",
> that's completely acceptable. I've been operating under the premise that it
> wouldn't be difficult to add such an option (just the hook, mind you, not the
> functionality behind it).

To answer your question from another post: If we add a hook, but not the
functionality behind it, then we are going to advertise something we
don't recommend to do on grounds that a random user might very well not
comprehend.  If we do add the functionality we might be better off with
an option rather than a hook, but then we incur the debt of having to
support it both in the syntax and the implementation.  That was the
reason I asked you about simply advising some function.  It doesn't
advertise some option that then isn't implemented and if someone really
cares about that functionality we can still show (even on Worg) how to
do it.  But not in the Org manual or as an official option.

[There was a precedent to this with Org 7 where you could go in and
change what Org considered a headline.  When this was changed we've had
similar discussions and I expect this one to take the same route to be
honest.]

> There is another vector to consider, and a far more nebulous one: How does it
> impact Org's "luft"? That is, the feeling of ease and comfort Org conveys in
> its use.

If you don't use properties then it doesn't affect you at all.  If you
do, then… well, I personally simply don't care.  Just like there's
several style guides for writing C; as long as these are applied
consistently I can live with most of them and put the braces and indents
the way they prescribe.

> There are many highly functional alternatives to Org that I've tried and
> rejected because they lack the easy grace of Org. That grace is why I've been
> able to stick with it after almost 9,000 handled tasks. Any perception of
> "inertia" in a tasking system causes me to psychologically avoid it, even if I
> have no rational basis for that aversion.
>
> I sincerely hope that those with high technical motives will keep in mind the
> usability of Org beyond purely technical considerations. It should say
> something that a long-time user is unhappy with the way Org "feels" in 8.3.

So write the advise and move on?  If you weren't so heavily invested in
what you perceive as "the right style" you quite likely wouldn't care,
or would you?


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] Allowing loose ordering in Org files

2015-11-10 Thread Achim Gratz
John Wiegley writes:
> In my regimen, every single entry has a PROPERTIES drawer, since I tag each
> one with ID and CREATED, for future reference. Most items are SCHEDULED as
> well. So when I open up a headline to look at the contents, I see:
>
> * Head
> SCHEDULED
> text
> :PROPERTIES:...
>
> It's a trivial thing, but I'd rather not scan past two lines to start reading
> my entry.

So isn't your request rather to hide the properties drawer better by
default?  You were _only_ talking about the UX in this whole thread and
that might be a lot easier to adapt while not changing the way Org
syntax is defined.

There were lots of bugs to be fixed with properties and properties
inheritance and I dabbled in that endeavour, which makes me more
cautious about wading in and changing it yet again.  Knowing where to
find the properties quickly is key to this not falling apart again,
IMHO.  Even then, due to inheritance properties are probably the most
complex thing to wrap your head around in Org aside from Babel.

[…]
> I *care*, which is maybe both a blessing and a curse. It is the origin of my
> creative contributions, but also the cause of these annoying threads. I'd
> rather work with you guys than against you; but there are some sacred cows
> that moan plaintively, when a sharp parenthesis is drawn across their throats.

As I said above, the solution may well be different than both what you
want to keep and what Org offers now.  I don't find that thread
particularly annoying, btw.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs




Re: [O] Allowing loose ordering in Org files

2015-11-09 Thread Achim Gratz
John Wiegley writes:
>> John Wiegley  writes:
>> I spoke to Nicolas directly and he mentioned that a goal for syntax
>> regularity is to make it possible to reliably read and manipulate Org files
>> outside of Emacs.

How about keeping the discussion on the list and stop Cc: and Reaply-To:
madness?

> I've had time this weekend to rethink my feature request, and I realized that
> even machine-friendly formatting is something I should be able to give up, to
> have an Org that works better for me.

The whole point of defining a formal syntax for Org is that it becomes
possible to parse Org documents with something other than Emacs and
still make sense of them.  To reap that benefit, you need to drop some
of the ad-hoc parsing that Org did in the past.

> What has always made Org great (to me) is that it's a rather "light" overlay
> on a plain old text file. What structure it does enforce -- say, the actual
> syntax of drawers -- has always felt fairly "fluid".

Still does.

> Lately there seems to be a push to sacrifice some of this freedom in order to
> gain efficiency and regularity. I imagine this is for the benefit of machine
> parsers; but what if one doesn't use any machine parsers? Org never asked me
> to give up flexibility for unknown benefits before.

Yes it did and still does, just in other places that you may or may not
care about.  For instance, it asks you to not use multi-line table
cells, or column and row spans.  It also doesn't let you use a :TBLFM:
drawer instead of that #+TBLFM: line just because it looks more neat (it
really should, BTW :-).

> It should be asked whether users want to trade formatting freedom for those
> benefits. If it has been asked, I missed that discussion. So unless it's an
> heavy maintenance burden to allow floating properties, for example, I don't
> see why I, as a user, shouldn't be allowed to make that choice.

I won't talk about "maintenance burden", but in any case it's a
technical debt.  You'd have to maintain two code paths that accomplish
the same result or at least should.

> To those who repeat the performance argument: This is an opt-in only request.
> It is not about changing the performance of default Org, or making files more
> difficult to parse outside of Emacs for everyone.

You will find that the argument really wasn't about performance, but
complexity.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: [O] Allowing loose ordering in Org files

2015-11-09 Thread Achim Gratz
John Wiegley writes:
>> You will find that the argument really wasn't about performance, but
>> complexity.
>
> I can accept a complexity argument,

I meant O() complexity, not implementation complexity.

> if my request were really "a separate
> code-path". I'm not sure it is. For example, my needs could be satisfied by
> something as simple as:
>
> (defun parse-org-entry (...)
> (let ((props (funcall 'parse-org-properties-function ...)))
>...))
>
> `parse-org-properties-function' would point to a function that does what Org
> 8.3 does now. This gives me the option of porting over the 8.2 version and
> keeping the old behavior. All that needs to be done is to allow this hook, no?

If it's not about providing the alternative behaviour within Org, then
what does this allow you to do that advising parse-org-entry can't?  A
hook still has the cost of simply being there even when I don't use it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada




Re: [O] Conditional link export?

2015-11-07 Thread Achim Gratz
Aaron Ecay writes:
> Someone ported the org manual to org format in a non-trivial way a
> couple of years ago .
> It generated a lot of discussion but was never finally adopted.  I
> believe that was due more to the difficulty in integrating the build
> process rather than anything wrong with the org version of the manual
> per se.  Speed may have also been a concern, but I expect the exporter
> to have gotten much faster in the intervening years.

The build process wasn't a problem, but speed arguably still is.  I
still have the corresponding extension in my local.mk file (I also
posted them on the list for others to re-use).


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] problems with export and :cache

2015-11-07 Thread Achim Gratz
Aaron Ecay writes:
>> Another option is to extend `org-babel-get-header' to accept a list of
>> keys instead of a single key.
>
> I’d like to remove this function, actually.  I hate the org functions
> that do X most of the time, but the opposite of X when you pass them
> an optional argument (in this case the third arg ‘other’).  Almost
> all (a couple dozen in total) of the calls to o-b-get-header are in
> the context (mapcar #'cdr (org-babel-get-header params :var)).  I’d
> like to introduce a function org-babel--get-var-values to cover these
> cases, and replace the remaining 2 calls in the codebase (which both
> extract :column-names) with assq (since :column-names should appear
> maximally once, unlike :var).  The sole use of the evil 'other arg is
> refactored away by my patch.

Your commit 0d000f5680 implementing this (I can't find the push
announced on the list, so I hope it's OK to piggy-back on here) breaks
the test ob-awk/tabular-input.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html




Re: [O] problems with export and :cache

2015-11-07 Thread Achim Gratz
Aaron Ecay writes:
>> Your commit 0d000f5680 implementing this (I can't find the push
>> announced on the list, so I hope it's OK to piggy-back on here) breaks
>> the test ob-awk/tabular-input.
>
> Thanks for the report.  Fixed in 4773baf.

Fix confirmed, thank you.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




Re: [O] bug in org-habits

2015-11-03 Thread Achim Gratz
John Wiegley writes:
> Thanks for discussing this with me, Nicolas. I appreciate there may be
> technical complexities involved. Could we special-case allow PROPERTIES to be
> the *very last thing* in an entry? I don't need it to float anywhere else. I
> just like it to be at the end.

Well, that's precisely the thing that doesn't scale and that Nicolas
wanted to avoid.  Putting the properties at the beginning of an entry
makes the search pretty much constant time and if you find something
else at the start of the entry then you know there aren't any and can go
on (this is pretty important for making sure property inheritance works
correctly, among other things).  If you could put them _anywhere_ else,
you'd have to keep searching until you either find them or you've
exhausted the span of the entry.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




Re: [O] bug in org-habits

2015-11-03 Thread Achim Gratz
John Wiegley writes:
>> Jonathan Leech-Pepin  writes:
>> Wouldn't last item in entry scale without issues? Find end of headline
>> (start of next or end of buffer) and search backwards. If first element from
>> end is a property drawer you have it, otherwise you still know there is
>> none.
>
> That sounds even better than what I mentioned about re-search-forward, and
> O(1) time complexity as well.

I don't think so.  Search for end of entry can be complex in itself and
you would never know if the properties you find by looking back aren't
belonging to an entry one level down unless you scanned the whole span
again.  Also, properties can be any size and you have to search for the
beginning of the drawer.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




Re: [O] Tamil unicode table column alignment

2015-10-14 Thread Achim Gratz
Shakthi Kannan writes:
> when I export to HTML the columns are neatly aligned. Is there a way
> to make them aligned in the buffer itself?

This works only if you use a font where all glyphs are the same width.


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] http address for cloning org-mode git

2015-09-24 Thread Achim Gratz
Suvayu Ali writes:
>> > That is a mirror, a relic from the old days when that used to be the
>> > official repo.  Maybe try:  http://orgmode.org/org-mode.git
>> 
>> No, that never was the official repo.  I've set up that mirror.
>
> Didn't we used to have the Org repo hosted on repo.or.cz way, way back
> in the old days, pre-2010?  Maybe I'm just confusing a different repo
> because it was on the same domain?

You're right, I didn't look closely enough.  The repo above is a mirror
that Bastien had created and it may well have been the "official" repo
for some time before orgmode.org was taking that position.  Sorry for
any confusion.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html




Re: [O] org-collector unable to handle macros

2015-09-24 Thread Achim Gratz
Nicolas Goaziou writes:
>> It seems that there is no table returned or the interpretation of the
>> returned data as a table fails.
>
> I just applied a patch that may fix these issues.

This bug is fixed, thank you.


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] http address for cloning org-mode git

2015-09-23 Thread Achim Gratz
Kaushal Modi writes:
> Today git pull gives the below error:
>
> Fetching origin
> fatal: unable to access 'http://repo.or.cz/r/org-mode.git/': Couldn't
> resolve host 'repo.or.cz'
> error: Could not fetch origin

That looks like a problem with DNS resolution on your side.

> ​Looks like ​
> http://repo.or.cz/r/org-mode.git/
> ​ is down? Is anyone else seeing the same thing? Is there an alternative
> http: address that I can use for cloning?

With a new enough Git you _can_ pull from

http://orgmode.org/orgmode.git

But it's probably not nice to the server.


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] http address for cloning org-mode git

2015-09-23 Thread Achim Gratz
Suvayu Ali writes:
> On Wed, Sep 23, 2015 at 03:03:42PM -0400, Kaushal Modi wrote:
>> I cannot access the git: repo address and so had been using the http:
>> version till now ( http://repo.or.cz/r/org-mode.git/ ).
>
> That is a mirror, a relic from the old days when that used to be the
> official repo.  Maybe try:  http://orgmode.org/org-mode.git

No, that never was the official repo.  I've set up that mirror.


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: [O] org-collector unable to handle macros

2015-09-23 Thread Achim Gratz
Nicolas Goaziou writes:
> Fixed. Thank you.

That commit 6d2ab4071960f8a7f20138291424b468722ab522 breaks three R
tests for me on Linux (not that other R tests do run correctly):

3 unexpected results:
   FAILED  test-ob-R/colnames-nil-header-argument
   FAILED  test-ob-R/colnames-no-header-argument
   FAILED  test-ob-R/colnames-yes-header-argument

It seems that there is no table returned or the interpretation of the
returned data as a table fails.

Test test-ob-R/colnames-nil-header-argument condition:
(user-error "Empty table - created default table")
   FAILED  130/599  test-ob-R/colnames-nil-header-argument
Test test-ob-R/colnames-no-header-argument condition:
(ert-test-failed
 ((should
   (equal '...
(org-babel-execute-src-block)))
  :form
  (equal
   (("col")
("a")
("b"))
   nil)
  :value nil :explanation
  (different-types
   (("col")
("a")
("b"))
   nil)))
   FAILED  131/599  test-ob-R/colnames-no-header-argument
Test test-ob-R/colnames-yes-header-argument condition:
(user-error "Empty table - created default table")
   FAILED  132/599  test-ob-R/colnames-yes-header-argument


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] Merge branch 'maint'

2015-09-11 Thread Achim Gratz

Am 11.09.2015 um 13:59 schrieb Oleh Krehel:

What is the purpose of maint exactly?


It's a bit short on the explanation side, but does that help?

http://orgmode.org/worg/dev/index.html

Also (not exactly the branch model ORg uses, but explains the issues in 
more detail):


http://nvie.com/posts/a-successful-git-branching-model/
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
http://williamdurand.fr/2012/01/17/my-git-branching-model/


In Emacs git repository there's
master and emacs24. All commits apply to master first, while some are
cherry picked onto emacs24. The emacs24 branch will never be merged into
master: it's divergent and that's fine.


You might want to check your facts (most recently, see for instance 
commit 59db4308b546).  Realitity simply doesn't conform to your 
world-view and the conclusions you draw from it are similarly distorted. 
 Cherry-picking from master to emacs24 is actually fixing a mistake 
made when committing a bug-fix to master.



As I understood, for Org mode some commits are applied to maint, and
then merged into master. Why?


Because that's how you make sure that bugfixes are applied to the 
releases in maint and get incorporated into master so that they don't 
vanish with the next release, all while each change appears exactly in 
one commit.



--
Achim.

(on the road :-)




  1   2   3   4   5   6   7   8   9   10   >