* org-crypt bug and other org inconveniences. @ 2013-11-19 15:51 Thierry Volpiatto 2013-11-19 16:41 ` Bastien 2013-11-19 18:10 ` Stefan Monnier 0 siblings, 2 replies; 11+ messages in thread From: Thierry Volpiatto @ 2013-11-19 15:51 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-19 15:51 org-crypt bug and other org inconveniences Thierry Volpiatto @ 2013-11-19 16:41 ` Bastien 2013-11-20 7:32 ` Thierry Volpiatto 2013-11-21 8:31 ` Thierry Volpiatto 2013-11-19 18:10 ` Stefan Monnier 1 sibling, 2 replies; 11+ messages in thread From: Bastien @ 2013-11-19 16:41 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-19 16:41 ` Bastien @ 2013-11-20 7:32 ` Thierry Volpiatto 2013-11-21 8:31 ` Thierry Volpiatto 1 sibling, 0 replies; 11+ messages in thread From: Thierry Volpiatto @ 2013-11-20 7:32 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-19 16:41 ` Bastien 2013-11-20 7:32 ` Thierry Volpiatto @ 2013-11-21 8:31 ` Thierry Volpiatto 2013-11-21 9:07 ` Bastien 1 sibling, 1 reply; 11+ messages in thread From: Thierry Volpiatto @ 2013-11-21 8:31 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-21 8:31 ` Thierry Volpiatto @ 2013-11-21 9:07 ` Bastien 0 siblings, 0 replies; 11+ messages in thread From: Bastien @ 2013-11-21 9:07 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-19 15:51 org-crypt bug and other org inconveniences Thierry Volpiatto 2013-11-19 16:41 ` Bastien @ 2013-11-19 18:10 ` Stefan Monnier 2013-11-20 7:45 ` Thierry Volpiatto 1 sibling, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2013-11-19 18:10 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-19 18:10 ` Stefan Monnier @ 2013-11-20 7:45 ` Thierry Volpiatto 2013-11-20 13:44 ` Stefan Monnier 2013-11-20 18:30 ` Bastien 0 siblings, 2 replies; 11+ messages in thread From: Thierry Volpiatto @ 2013-11-20 7:45 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-20 7:45 ` Thierry Volpiatto @ 2013-11-20 13:44 ` Stefan Monnier 2013-11-20 14:20 ` Thierry Volpiatto 2013-11-20 18:30 ` Bastien 1 sibling, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2013-11-20 13:44 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-20 13:44 ` Stefan Monnier @ 2013-11-20 14:20 ` Thierry Volpiatto 2013-11-20 18:29 ` Bastien 0 siblings, 1 reply; 11+ messages in thread From: Thierry Volpiatto @ 2013-11-20 14:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-20 14:20 ` Thierry Volpiatto @ 2013-11-20 18:29 ` Bastien 0 siblings, 0 replies; 11+ messages in thread From: Bastien @ 2013-11-20 18:29 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: Stefan Monnier, emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: org-crypt bug and other org inconveniences. 2013-11-20 7:45 ` Thierry Volpiatto 2013-11-20 13:44 ` Stefan Monnier @ 2013-11-20 18:30 ` Bastien 1 sibling, 0 replies; 11+ messages in thread From: Bastien @ 2013-11-20 18:30 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-11-21 9:07 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-19 15:51 org-crypt bug and other org inconveniences Thierry Volpiatto 2013-11-19 16:41 ` Bastien 2013-11-20 7:32 ` Thierry Volpiatto 2013-11-21 8:31 ` Thierry Volpiatto 2013-11-21 9:07 ` Bastien 2013-11-19 18:10 ` Stefan Monnier 2013-11-20 7:45 ` Thierry Volpiatto 2013-11-20 13:44 ` Stefan Monnier 2013-11-20 14:20 ` Thierry Volpiatto 2013-11-20 18:29 ` Bastien 2013-11-20 18:30 ` Bastien
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).