Release 9.0.5

Release 9.0.5

[Bastien]

Hi all,

Org 9.0.5, a minor bugfix release, is out.

Thanks!

-- 
 Bastien

Re: Release 9.0.5

[Jorge Morais Neto]

On 10 February 2017 at 11:53, Bastien <bzg@gnu.org> wrote:
> Org 9.0.5, a minor bugfix release, is out.
In Org 9.0.5, clock out notes are again stored below the corresponding
clock line, restoring the behavior of an earlier release.  There were
interim releases, up to 9.0.4, that stored the clock out notes /above/
the clock line. Users should be warned to fix clock out notes taken by
affected Org releases.  Existing important data following the interim
convention need to be fixed, transposing each affected clock out note
with the clock line.  If both conventions are mixed, then, to identify
which clock line corresponds to each clock out note, either the user
will need to remember the time period when they used an affected
release, or remember directly which clock out line corresponds to each
ambiguous note, or analise the version history of their Org files.  So
the longer the user takes to address the problem, the greater the
chance of data loss.  I think this issue is important.

Could we provide an Elisp function to fix this semi-automatically?

Regards
-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

Re: Release 9.0.5

[Bastien Guerry]

Hi Jorge,

Jorge Morais Neto <jorge13515@gmail.com> writes:

> Could we provide an Elisp function to fix this semi-automatically?

I have been affected by this problem too.  I don't have my computer
this week-end, but I'll have a close look on monday.

Thanks,

-- 
 Bastien

location of clocking out notes (was: Re: Release 9.0.5)

[Gregor Zattler]

Hi Jorge, Bastien, org-mode developers,
* Jorge Morais Neto <jorge13515@gmail.com> [10. Feb. 2017]:
> On 10 February 2017 at 11:53, Bastien <bzg@gnu.org> wrote:
>> Org 9.0.5, a minor bugfix release, is out.
> In Org 9.0.5, clock out notes are again stored below the corresponding
> clock line, restoring the behavior of an earlier release.  There were
> interim releases, up to 9.0.4, that stored the clock out notes /above/
> the clock line.

Is there a consensus now where the clocking out notes should go,
even in future versions?  I am affected from this too and before
I start changing the position of all the clocking out notes I
would like to know where to move them.

> Users should be warned to fix clock out notes taken by
> affected Org releases.  Existing important data following the interim
> convention need to be fixed, transposing each affected clock out note
> with the clock line.  If both conventions are mixed, then, to identify
> which clock line corresponds to each clock out note, either the user
> will need to remember the time period when they used an affected
> release, or remember directly which clock out line corresponds to each
> ambiguous note, or analise the version history of their Org files.  So
> the longer the user takes to address the problem, the greater the
> chance of data loss.  I think this issue is important.
> 
> Could we provide an Elisp function to fix this semi-automatically?

This would be great.

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: location of clocking out notes

[Nicolas Goaziou]

Hello,

Gregor Zattler <telegraph@gmx.net> writes:

> Is there a consensus now where the clocking out notes should go,
> even in future versions?  I am affected from this too and before
> I start changing the position of all the clocking out notes I
> would like to know where to move them.

I think the current location is the expected one.

Regards,

-- 
Nicolas Goaziou

Re: Release 9.0.5

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 912 bytes --]

Hi Bastien and list,

I have updated Org this morning from the master branch and I have a problem.
Inserting a link as the first element of a line result in a strange
behaviour.
Sometimes, the link is not indented as it should relatively to the header
above,
and the link seems to continue after the eol. Look at the printscreen :

[image: Images intégrées 1]

I can't add a new line after the link.
Anybody has already seen something like this ?

Thanks for any clue in fixing this problem.

Fabrice

2017-02-10 14:53 GMT+01:00 Bastien <bzg@gnu.org>:

> Hi all,
>
> Org 9.0.5, a minor bugfix release, is out.
>
> Thanks!
>
> --
>  Bastien
>
>
>


-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #1.2: Type: text/html, Size: 1692 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 14255 bytes --]

Re: Release 9.0.5

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 1667 bytes --]

Maybe this explains it :

Ran 670 tests, 667 results as expected, 3 unexpected (2017-02-10
22:35:45+0100)
14 expected failures

3 unexpected results:
   FAILED  test-org-element/link-parser
   FAILED  test-org-export/file-uri
   FAILED  test-org-pcomplete/keyword

But it is still not a fix :-/

Fabrice

2017-02-10 21:25 GMT+01:00 Fabrice Popineau <fabrice.popineau@supelec.fr>:

> Hi Bastien and list,
>
> I have updated Org this morning from the master branch and I have a
> problem.
> Inserting a link as the first element of a line result in a strange
> behaviour.
> Sometimes, the link is not indented as it should relatively to the header
> above,
> and the link seems to continue after the eol. Look at the printscreen :
>
> [image: Images intégrées 1]
>
> I can't add a new line after the link.
> Anybody has already seen something like this ?
>
> Thanks for any clue in fixing this problem.
>
> Fabrice
>
> 2017-02-10 14:53 GMT+01:00 Bastien <bzg@gnu.org>:
>
>> Hi all,
>>
>> Org 9.0.5, a minor bugfix release, is out.
>>
>> Thanks!
>>
>> --
>>  Bastien
>>
>>
>>
>
>
> --
> Fabrice Popineau
> -----------------------------
> SUPELEC
> Département Informatique
> 3, rue Joliot Curie
> 91192 Gif/Yvette Cedex
> Tel direct : +33 (0) 169851950 <01%2069%2085%2019%2050>
> Standard : +33 (0) 169851212 <01%2069%2085%2012%2012>
> ------------------------------
>
>


-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #1.2: Type: text/html, Size: 3234 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 14255 bytes --]

Re: Release 9.0.5

[Fabrice Popineau]

[-- Attachment #1.1: Type: text/plain, Size: 2296 bytes --]

Sorry for the noise.
I found the culprit and it was on my side.
Everything is working again
but there are still 3 unexpected failures to the tests.

Regards


2017-02-10 22:37 GMT+01:00 Fabrice Popineau <fabrice.popineau@supelec.fr>:

> Maybe this explains it :
>
> Ran 670 tests, 667 results as expected, 3 unexpected (2017-02-10
> 22:35:45+0100)
> 14 expected failures
>
> 3 unexpected results:
>    FAILED  test-org-element/link-parser
>    FAILED  test-org-export/file-uri
>    FAILED  test-org-pcomplete/keyword
>
> But it is still not a fix :-/
>
> Fabrice
>
> 2017-02-10 21:25 GMT+01:00 Fabrice Popineau <fabrice.popineau@supelec.fr>:
>
>> Hi Bastien and list,
>>
>> I have updated Org this morning from the master branch and I have a
>> problem.
>> Inserting a link as the first element of a line result in a strange
>> behaviour.
>> Sometimes, the link is not indented as it should relatively to the header
>> above,
>> and the link seems to continue after the eol. Look at the printscreen :
>>
>> [image: Images intégrées 1]
>>
>> I can't add a new line after the link.
>> Anybody has already seen something like this ?
>>
>> Thanks for any clue in fixing this problem.
>>
>> Fabrice
>>
>> 2017-02-10 14:53 GMT+01:00 Bastien <bzg@gnu.org>:
>>
>>> Hi all,
>>>
>>> Org 9.0.5, a minor bugfix release, is out.
>>>
>>> Thanks!
>>>
>>> --
>>>  Bastien
>>>
>>>
>>>
>>
>>
>> --
>> Fabrice Popineau
>> -----------------------------
>> SUPELEC
>> Département Informatique
>> 3, rue Joliot Curie
>> 91192 Gif/Yvette Cedex
>> Tel direct : +33 (0) 169851950 <01%2069%2085%2019%2050>
>> Standard : +33 (0) 169851212 <01%2069%2085%2012%2012>
>> ------------------------------
>>
>>
>
>
> --
> Fabrice Popineau
> -----------------------------
> SUPELEC
> Département Informatique
> 3, rue Joliot Curie
> 91192 Gif/Yvette Cedex
> Tel direct : +33 (0) 169851950 <01%2069%2085%2019%2050>
> Standard : +33 (0) 169851212 <01%2069%2085%2012%2012>
> ------------------------------
>
>


-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #1.2: Type: text/html, Size: 4630 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 14255 bytes --]

Re: Release 9.0.5

[Nicolas Goaziou]

Hello,

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

> Sorry for the noise.
> I found the culprit and it was on my side.
> Everything is working again
> but there are still 3 unexpected failures to the tests.

FWIW, i cannot reproduce it. Neither can the BuildBot.

Regards,

-- 
Nicolas Goaziou

Re: Release 9.0.5

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]

Thanks Nicolas for the confirmation.

I am running Emacs 25.2rc2 under Windows 10 compiled with Mingw64.
2 of the failures seem to be harmless.

This one is about the file system which behaves differently under Windows :

F test-org-export/file-uri
    Test ‘org-export-file-uri’ specifications.
    (ert-test-failed
     ((should
       (equal "file:///local.org"
     (org-export-file-uri "/local.org")))
      :form
      (equal "file:///local.org" "file://d:/local.org")
      :value nil :explanation
      (arrays-of-different-length 17 19 "file:///local.org" "file://d:/
local.org" first-mismatch-at 7)))

The absolute path has the drive name. So actually not a failure.

F test-org-pcomplete/keyword
    Test keyword and block completion.
    (ert-test-failed
     ((should
       (equal "#+startup: "
     (org-test-with-temp-text "#+start<point>"
(pcomplete)
(buffer-string))))
      :form
      (equal "#+startup: " "#+STARTUP: ")
      :value nil :explanation
      (array-elt 2
(different-atoms
 (115 "#x73" "?s")
 (83 "#x53" "?S")))))

This one is because pcomplete is used to get completion, and the completion
depends on
the pcomplete-ignore-case variable, which makes pcomplete ignore case for
windows-nt and cygwin by default.

The last one is strange:

F test-org-element/link-parser
    Test ‘link’ parser.
    (ert-test-failed
     ((should
       (equal "id"
     (org-test-with-temp-text "[[id:aaaa]]"
(org-element-property :type ...))))
      :form
      (equal "id" "fuzzy")
      :value nil :explanation
      (arrays-of-different-length 2 5 "id" "fuzzy" first-mismatch-at 0)))

This is complete non sense, because when I evaluate the test form, I
actually get "id" and I have
no idea where this "fuzzy" may come from.

Do you also get a warning like this:
Making org-entities-user local to  *temp*-443480 while let-bound!
in the *Messages* buffer ?

Fabrice

2017-02-11 1:47 GMT+01:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>:

> Hello,
>
> Fabrice Popineau <fabrice.popineau@supelec.fr> writes:
>
> > Sorry for the noise.
> > I found the culprit and it was on my side.
> > Everything is working again
> > but there are still 3 unexpected failures to the tests.
>
> FWIW, i cannot reproduce it. Neither can the BuildBot.
>
> Regards,
>
> --
> Nicolas Goaziou
>



-- 
Fabrice Popineau
-----------------------------
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #2: Type: text/html, Size: 4999 bytes --]

Re: Release 9.0.5

[Nicolas Goaziou]

Hello,

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

> This one is about the file system which behaves differently under Windows :
>
> F test-org-export/file-uri
>     Test ‘org-export-file-uri’ specifications.
>     (ert-test-failed
>      ((should
>        (equal "file:///local.org"
>      (org-export-file-uri "/local.org")))
>       :form
>       (equal "file:///local.org" "file://d:/local.org")
>       :value nil :explanation
>       (arrays-of-different-length 17 19 "file:///local.org" "file://d:/
> local.org" first-mismatch-at 7)))
>
> The absolute path has the drive name. So actually not a failure.

Ok. I rewrote the equality test. Hopefully, it should pass on your
system.

> F test-org-pcomplete/keyword
>     Test keyword and block completion.
>     (ert-test-failed
>      ((should
>        (equal "#+startup: "
>      (org-test-with-temp-text "#+start<point>"
> (pcomplete)
> (buffer-string))))
>       :form
>       (equal "#+startup: " "#+STARTUP: ")
>       :value nil :explanation
>       (array-elt 2
> (different-atoms
>  (115 "#x73" "?s")
>  (83 "#x53" "?S")))))
>
> This one is because pcomplete is used to get completion, and the completion
> depends on
> the pcomplete-ignore-case variable, which makes pcomplete ignore case for
> windows-nt and cygwin by default.

I also fixed it.

> The last one is strange:
>
> F test-org-element/link-parser
>     Test ‘link’ parser.
>     (ert-test-failed
>      ((should
>        (equal "id"
>      (org-test-with-temp-text "[[id:aaaa]]"
> (org-element-property :type ...))))
>       :form
>       (equal "id" "fuzzy")
>       :value nil :explanation
>       (arrays-of-different-length 2 5 "id" "fuzzy" first-mismatch-at 0)))

I removed this particular test. "id" links are non-standard (i.e., they
need you to require Org ID library). Such a test should go in
"test-org-id.el", which doesn't exist yet.

> This is complete non sense, because when I evaluate the test form, I
> actually get "id" and I have
> no idea where this "fuzzy" may come from.

A "fuzzy" link is a link with no default type, per
`org-link-parameters'. It probably means `org-id' wasn't loaded at the
time of the test.

> Do you also get a warning like this:
> Making org-entities-user local to  *temp*-443480 while let-bound!
> in the *Messages* buffer ?

I don't.

Could you confirm tests are passing now?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: Release 9.0.5

[Colin Baxter]

On Fri, Feb 10 2017, Fabrice Popineau wrote:

> Maybe this explains it :
>
> Ran 670 tests, 667 results as expected, 3 unexpected (2017-02-10 22:35:45+0100)
> 14 expected failures
>
> 3 unexpected results:
> FAILED test-org-element/link-parser
> FAILED test-org-export/file-uri
> FAILED test-org-pcomplete/keyword
>
> But it is still not a fix :-/
>
> Fabrice
>
> 2017-02-10 21:25 GMT+01:00 Fabrice Popineau <fabrice.popineau@supelec.fr>:
>
>  Hi Bastien and list,
>
>  I have updated Org this morning from the master branch and I have a problem.
>  Inserting a link as the first element of a line result in a strange behaviour. 
>  Sometimes, the link is not indented as it should relatively to the header above, 
>  and the link seems to continue after the eol. Look at the printscreen :
>
> Images intégrées 1
>
>  I can't add a new line after the link.
>  Anybody has already seen something like this ?
>
>  Thanks for any clue in fixing this problem.
>
>  Fabrice
>
>  2017-02-10 14:53 GMT+01:00 Bastien <bzg@gnu.org>:
>
>  Hi all,
>
>  Org 9.0.5, a minor bugfix release, is out.
>
>  Thanks!
>
>  --
>  Bastien
>
>  -- 
>  Fabrice Popineau
>  -----------------------------
>  SUPELEC
>  Département Informatique
>  3, rue Joliot Curie
>  91192 Gif/Yvette Cedex
>  Tel direct : +33 (0) 169851950
>  Standard : +33 (0) 169851212
>  ------------------------------

If it's any help, I get:

Ran 703 tests, 703 results as expected (2017-02-11 09:25:24+0000)
8 expected failures

with release_9.0.5-262-g0fe987.

In compiling, there is however the warning:

In org-create-formula-image:
org.el:19419:16:Warning: org-latex-make-preamble called with 3 arguments, but
accepts only 1-2


Colin.

Re: Release 9.0.5

[Russell Adams]

On Fri, Feb 10, 2017 at 02:53:56PM +0100, Bastien wrote:
> Hi all,
>
> Org 9.0.5, a minor bugfix release, is out.

With the other responses I wanted to add that I upgraded to 9.0.4 this
morning and it broke babel executing shell code. I updated to 9.0.5 as
soon as it was available and it fixed it.

I appreciate the fixes!



------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Merge 9.0.5 to emacs master? (Was: Release 9.0.5)

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Thanks Bastien.

Kyle -- Would this be a good time to start the merge to emacs master?

My datapoint -- I have been using emacs master + org master for over a year
now (or few years). So I am for doing the merge directly into the master
branch.

Thanks.

On Fri, Feb 10, 2017 at 8:55 AM Bastien <bzg@gnu.org> wrote:

> Hi all,
>
> Org 9.0.5, a minor bugfix release, is out.
>
> Thanks!
>
> --
>  Bastien
>
>
> --

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1037 bytes --]

Re: Merge 9.0.5 to emacs master? (Was: Release 9.0.5)

[Kyle Meyer]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Kyle -- Would this be a good time to start the merge to emacs master?

From my standpoint, that'd be fine.  I'm not aware of any outstanding
patches that need to be backported from the Emacs repo.

-- 
Kyle

Re: Merge 9.0.5 to emacs master?

[Bastien Guerry]

Hi Kyle,

Kyle Meyer <kyle@kyleam.com> writes:

> Kaushal Modi <kaushal.modi@gmail.com> writes:
>
>> Kyle -- Would this be a good time to start the merge to emacs master?
>
>From my standpoint, that'd be fine.  I'm not aware of any outstanding
> patches that need to be backported from the Emacs repo.

Before undertaking this, we need to make sure the Emacs maintainers
are fine with it -- I'm late in reading the related discussions.

Can you wait a few days for my "go" ?

Thanks,

-- 
 Bastien

Re: Merge 9.0.5 to emacs master?

[Kyle Meyer]

Hi Bastien,

Bastien Guerry <bzg@gnu.org> writes:

> Kyle Meyer <kyle@kyleam.com> writes:
>
>> Kaushal Modi <kaushal.modi@gmail.com> writes:
>>
>>> Kyle -- Would this be a good time to start the merge to emacs master?
>>
>>From my standpoint, that'd be fine.  I'm not aware of any outstanding
>> patches that need to be backported from the Emacs repo.
>
> Before undertaking this, we need to make sure the Emacs maintainers
> are fine with it -- I'm late in reading the related discussions.
>
> Can you wait a few days for my "go" ?

I'll do better than that and wait indefinitely since the plan isn't for
me to do the syncing :)

To give a bit more context to Kaushal's question, when he asked the list
previously [*1*] about syncing 9.0.4 with the Emacs repo, I replied
[*2*, *3*] that we should wait for the next release because there were
Emacs commits that still needed to be backported, as well as white space
touch-ups that were needed in order for the Org files to pass Emacs's
pre-commit check.

I also mentioned [*2*] that I had created a branch, emacs-sync, in the
Org repo that contains a few extra changes that I think are appropriate
for the sync.  That branch is up-to-date with 9.0.5.


[*1*] https://lists.gnu.org/archive/html/emacs-orgmode/2017-01/msg00551.html
[*2*] https://lists.gnu.org/archive/html/emacs-orgmode/2017-01/msg00571.html
[*3*] https://lists.gnu.org/archive/html/emacs-orgmode/2017-01/msg00584.html

-- 
Kyle

Re: Merge 9.0.5 to emacs master?

[Rasmus]

Kyle Meyer <kyle@kyleam.com> writes:

> Hi Bastien,
>
> Bastien Guerry <bzg@gnu.org> writes:
>
>> Kyle Meyer <kyle@kyleam.com> writes:
>>
>>> Kaushal Modi <kaushal.modi@gmail.com> writes:
>>>
>>>> Kyle -- Would this be a good time to start the merge to emacs master?
>>>
>>>From my standpoint, that'd be fine.  I'm not aware of any outstanding
>>> patches that need to be backported from the Emacs repo.
>>
>> Before undertaking this, we need to make sure the Emacs maintainers
>> are fine with it -- I'm late in reading the related discussions.
>>
>> Can you wait a few days for my "go" ?
>
> I'll do better than that and wait indefinitely since the plan isn't for
> me to do the syncing :)

I also haven't caught up with all the messages about sync the "new" plans.
AFAIR Eli said to go ahead in one of the early messages.

> I also mentioned [*2*] that I had created a branch, emacs-sync, in the
> Org repo that contains a few extra changes that I think are appropriate
> for the sync.  That branch is up-to-date with 9.0.5.

I think we have discussed it before, but the best way seems to just copy
the Org tree to the Emacs tree, right?

Rasmus

-- 
Summon the Mothership!

Re: Merge 9.0.5 to emacs master?

[Kyle Meyer]

Rasmus <rasmus@gmx.us> writes:

[...]

> I think we have discussed it before, but the best way seems to just copy
> the Org tree to the Emacs tree, right?

Given the current setup, I think copying the files is best.  I've
already resolved the conflicts when backporting Org-related commits from
the Emacs repo.

-- 
Kyle

Re: Merge 9.0.5 to emacs master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On Mon, Feb 13, 2017, 1:40 PM Kyle Meyer <kyle@kyleam.com> wrote:

> Rasmus <rasmus@gmx.us> writes:
>
> [...]
>
> > I think we have discussed it before, but the best way seems to just copy
> > the Org tree to the Emacs tree, right?
>
> Given the current setup, I think copying the files is best.  I've
> already resolved the conflicts when backporting Org-related commits from
> the Emacs repo.
>

Just a minor nudge.

If I understand correctly, everyone is in agreement that the org maint
branch should be merged into emacs master branch now.

This issue came up recently in an emacs-devel discussion.

I don't have experience merging mega branches, but I can help in any other
way in that direction.

> --

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1578 bytes --]