org-crypt bug and other org inconveniences.

org-crypt bug and other org inconveniences.

[Thierry Volpiatto]

Hi all,

I sent a bug about org-crypt months ago (with patch to fix it).
I see org have been merged into trunk and the bug is still here...

,----
| Making epg-context local to  *epg* while let-bound!
`----


Also functions/vars have been removed without infos on how to replace
them.

At least `org-additional-option-like-keywords' and
`org-get-current-options'.

So I am dropping the support for org-keywords in helm as I don't want to
reread the whole org.el file.
 
-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: org-crypt bug and other org inconveniences.

[Bastien]

Hi Thierry,

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> I sent a bug about org-crypt months ago (with patch to fix it).
> I see org have been merged into trunk and the bug is still here...
>
> ,----
> | Making epg-context local to  *epg* while let-bound!
> `----

Yes, your message is here:
http://article.gmane.org/gmane.emacs.bugs/77307

I wasn't sure what I could do about it and I'm not Org
maintainer anymore.

I recommend you send this bug reports to the Org-mode list
directly, that's the best way to get a quick reply.

> Also functions/vars have been removed without infos on how to replace
> them.
>
> At least `org-additional-option-like-keywords' and
> `org-get-current-options'.

This is in the Emacs Changelog:

* org.el (org-additional-option-like-keywords): Remove variable.
(org-get-export-keywords): New function.
(org-options-keywords): Update default list of keywords.

* org-macs.el (org-default-options): Rename and adapt from
`org-get-current-options'.

You need to use `org-options-keywords' and `org-default-options'.

> So I am dropping the support for org-keywords in helm as I don't want to
> reread the whole org.el file.

Please read etc/ORG-NEWS and lisp/org/ChangeLog for such informations
and let me know if I can help.

-- 
 Bastien

Re: org-crypt bug and other org inconveniences.

[Thierry Volpiatto]

Hi Bastien,

Bastien <bzg@gnu.org> writes:

> I recommend you send this bug reports to the Org-mode list
> directly, that's the best way to get a quick reply.

Ok thanks.

> You need to use `org-options-keywords' and `org-default-options'.

Great, thanks for this, I will have a look.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: org-crypt bug and other org inconveniences.

[Thierry Volpiatto]

Bastien <bzg@gnu.org> writes:

> You need to use `org-options-keywords' and `org-default-options'.

Ok for `org-options-keywords' but `org-default-options' doesn't exists,
and I didn't find the equivalent of `org-get-current-options'.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: org-crypt bug and other org inconveniences.

[Bastien]

Hi Thierry,

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> You need to use `org-options-keywords' and `org-default-options'.
>
> Ok for `org-options-keywords' but `org-default-options' doesn't
> exists,

Right, sorry, it has been removed -- this is in the ChangeLog:

  * org-macs.el (org-default-options): Removed function.

> and I didn't find the equivalent of `org-get-current-options'.

There is none to my knowledge.  This is something I've asked Nicolas
to keep for backward compatibility, but that was not easy to do.

Feel free to raise this again on the mailling list, because I know
there are other people who need this.

-- 
 Bastien

Re: org-crypt bug and other org inconveniences.

[Stefan Monnier]

> I sent a bug about org-crypt months ago (with patch to fix it).
> I see org have been merged into trunk and the bug is still here...
> ,----
> | Making epg-context local to  *epg* while let-bound!
> `----

Note that this warning is not necessarily a problem.  Actually, I tend
to think we should just get rid of this warning (which I added, a few
years ago).

> So I am dropping the support for org-keywords in helm as I don't want to
> reread the whole org.el file.
 
BTW, why not try to push Helm's support for Org to Org, i.e. make Org
support Helm, rather than the other way around?

I think Helm (and company-mode, auto-complete, ...) should always go in
that direction: provide the infrastructure and then get the various
other modes to use that infrastructure, rather than add separate ad-hoc
glue-code which tends to need to be maintained on the wrong side of
the fence (as seen here).


        Stefan

Re: org-crypt bug and other org inconveniences.

[Thierry Volpiatto]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Note that this warning is not necessarily a problem.  Actually, I tend
> to think we should just get rid of this warning (which I added, a few
> years ago).

Yes, setting a var locally already let-bounded works actually.
But it is not what the documentation say.

,----
| Making a variable buffer-local within a `let'-binding for that
| variable does not work reliably, unless the buffer in which you do
| this is not current either on entry to or exit from the `let'.
| This is because `let' does not distinguish between different kinds
| of bindings; it knows only which variable the binding was made for.
`----


> BTW, why not try to push Helm's support for Org to Org, i.e. make Org
> support Helm, rather than the other way around?

Sure, but I don't think org developers want to maintain/develop code
depending on external applications.
Emacs developers too I think, (AFAIK sending a patch to emacs handling
external dependencies have been always refused).

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: org-crypt bug and other org inconveniences.

[Stefan Monnier]

>> Note that this warning is not necessarily a problem.  Actually, I tend
>> to think we should just get rid of this warning (which I added, a few
>> years ago).
> Yes, setting a var locally already let-bounded works actually.
> But it is not what the documentation say.

> ,----
> | Making a variable buffer-local within a `let'-binding for that
> | variable does not work reliably, unless the buffer in which you do
> | this is not current either on entry to or exit from the `let'.
> | This is because `let' does not distinguish between different kinds
> | of bindings; it knows only which variable the binding was made for.
> `----

The documentation is indeed rather conservative.  But it is true that
over the years many bugs were found in this area (and fixed).
AFAIK there are no remaining bugs in this area (no proof of it, but
I did try to consider "all possible cases"), *but* the "right behavior"
in some cases is not always completely well-defined.  E.g.:

    <...global value of x = 1...>
    (let ((x 2))
      (make-local-variable 'x))

After this code (default-value 'x) should have value 1.
But what about the buffer-local value of x?

So the above comment basically tries to scare coders away from mixing
let-bindings and buffer-local bindings, because "there be dragons".

>> BTW, why not try to push Helm's support for Org to Org, i.e. make Org
>> support Helm, rather than the other way around?
> Sure, but I don't think org developers want to maintain/develop code
> depending on external applications.
> Emacs developers too I think, (AFAIK sending a patch to emacs handling
> external dependencies have been always refused).

If the interface is sufficiently clean and generic, I'd definitely
consider it.  Can't speak for Org people.


        Stefan


PS: Last time we talked about including Helm in GNU ELPA, there were
issues about copyright, IIRC.  If those issues are mostly in the various
mode-specific support files, we could focus on integrating the
infrastructure part of Helm separately.

Re: org-crypt bug and other org inconveniences.

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Note that this warning is not necessarily a problem.  Actually, I tend
>>> to think we should just get rid of this warning (which I added, a few
>>> years ago).
>> Yes, setting a var locally already let-bounded works actually.
>> But it is not what the documentation say.
>
>> ,----
>> | Making a variable buffer-local within a `let'-binding for that
>> | variable does not work reliably, unless the buffer in which you do
>> | this is not current either on entry to or exit from the `let'.
>> | This is because `let' does not distinguish between different kinds
>> | of bindings; it knows only which variable the binding was made for.
>> `----
>
> The documentation is indeed rather conservative.  But it is true that
> over the years many bugs were found in this area (and fixed).
> AFAIK there are no remaining bugs in this area (no proof of it, but
> I did try to consider "all possible cases"), *but* the "right behavior"
> in some cases is not always completely well-defined.  E.g.:
>
>     <...global value of x = 1...>
>     (let ((x 2))
>       (make-local-variable 'x))
>
> After this code (default-value 'x) should have value 1.
> But what about the buffer-local value of x?
>
> So the above comment basically tries to scare coders away from mixing
> let-bindings and buffer-local bindings, because "there be dragons".

Agree. I have fixed all my code last year according to your warning.
So probably it is good to keep the warning and fix all the code that
trigger it ?

The patch about org-crypt does this (It is in my .emacs for months now).

>>> BTW, why not try to push Helm's support for Org to Org, i.e. make Org
>>> support Helm, rather than the other way around?
>> Sure, but I don't think org developers want to maintain/develop code
>> depending on external applications.
>> Emacs developers too I think, (AFAIK sending a patch to emacs handling
>> external dependencies have been always refused).
>
> If the interface is sufficiently clean and generic, I'd definitely
> consider it.  Can't speak for Org people.
Ok I will remember it, thanks.

> PS: Last time we talked about including Helm in GNU ELPA, there were
> issues about copyright, IIRC.  If those issues are mostly in the various
> mode-specific support files, we could focus on integrating the
> infrastructure part of Helm separately.

I have modified now most of the code during last two years.
But part of this code is still from somebody else even if massively
modified, so I don't know.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: org-crypt bug and other org inconveniences.

[Bastien]

Hi Thierry,

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> The patch about org-crypt does this (It is in my .emacs for months
> now).

I've now applied it to Org's git maintainance branch, it will
be part of Org 8.2.4 which will be merged before the end of the
year.

Thanks,

-- 
 Bastien

Re: org-crypt bug and other org inconveniences.

[Bastien]

Hi Thierry,

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Sure, but I don't think org developers want to maintain/develop code
> depending on external applications.

The best way to know is to ask on Org's mailing list: maybe there are
Helm users who will volunteer.

FWIW we do maintain quite a lot of code that depends on external
packages or programs, all this code is in the contrib/ directory.

Best,

-- 
 Bastien