emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [bug] Symbol's function definition is void: org-pop-to-buffer-sa


From: Sebastien Vauban
Subject: Re: [O] [bug] Symbol's function definition is void: org-pop-to-buffer-same-window
Date: Wed, 07 Dec 2011 21:45:57 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (windows-nt)

Hi all,

"Sebastien Vauban" wrote:
> Nick Dokos wrote:
>> Shelagh Manton <address@hidden> wrote:
>>> On Tue, 06 Dec 2011 16:19:36 -0500, Nick Dokos wrote:
>>>> Shelagh Manton <address@hidden> wrote:
>>>>> On Thu, 01 Dec 2011 11:40:11 -0300, Kenny Meyer wrote:
>>>>>> On Thu, Dec 1, 2011 at 9:51 AM, Sebastien Vauban
>>>>>>> In conditions which I consider unchanged (I speak of my emacs config
>>>>>>> file), with the latest Org-mode version, I now have the message:

There was the original mistake: conditions were changed!

>>>>>>>   let*: Symbol's function definition is void:
>>>>>>>   org-pop-to-buffer-same-window
>>>>>>>
>>>>>>> when doing, for example, `C-c C-x C-j' to jump on the currently
>>>>>>> clocked item.
>>>>>>>
>>>>>>> Explicitly Loading `org-compat' does cure this problem... But we
>>>>>>> must miss a `require' somewhere, but where?  In `org.el' itself?
>>>>>
>>>>> I've just been bitten by this as well. requiring org-compat manually did
>>>>> nothing. My config files have not changed, just pulled latest org-mode,
>>>>> did a make clean and make. Suddenly my org-drill sessions don't work.
>>>>
>>>> Did you restart emacs?
>>>
>>> Yes. I did just then and same thing.
>>
>> Do you get the error with org-drill only or do you get it in the instances
>> that Seb and Kenny Meyer report? If the former, it may be a bug with
>> org-drill. Otherwise, I throw up my hands: I certainly cannot reproduce it.
>
> FYI:
>
> - I don't use .elc files.
>
> - I've recently upgraded to Emacs 24.0.91.1 on Windows -- not sure if the
>   problem appeared directly after, or a little bit before.
>
> - I began suspecting work that I could have done in a branch, and mixed
>   versions that way -- as I'm not yet familiar with git and switching between
>   branches.
>
> - I've deleted all my Org directory, and cloned a fresh one
>
> But it still occurs.
>
> Though:
>
> - Requiring org-compat does cure the problem.
>
> - I see calls to org-compat in every crucial Org file -- I don't understand
>   where it could be missing.
>
> - I still must try to dissecate my .emacs, or use a minimal Emacs config file
>   to see if it's reproducible that way.

So, what was the problem in my case?  I've been trying to use the "starter
kit" approach, and have a "2-file" system:

- ~/.emacs

- ~/emacs/site-lisp/seb-conf.el (tangled from its .txt equivalent)
  which contains "add-to-load-path" calls for all packages (Org, Gnus, etc.)
  and all my customization.

In ~/.emacs, I've replaced my previous:

    (require 'seb-conf)

by

    (defun starter-kit-load ...)
    (defun starter-kit-compile ...)
    (starter-kit-load "emacs/site-lisp/seb-conf.txt")

Doing so, as it now calls `org-babel-load-file' (in `starter-kit-load'), and
as that function is autoloaded in Emacs 24, Emacs was loading the Org version
bundled with Emacs 24.0.91.1 -- that is, not the latest one, not the one in my
Git working copy.

This is very tricky to spot, IMHO, as all the checks done after Emacs has been
started up will give partially false answers:

    (locate-library "org-compat") shows my git version

as the load-path has been updated at the very beginning of loading `seb-conf'.

In summary:

- this is explained, and due to a mistake of mine;
- this is quite tricky to detect;
- this is a mix of different Org versions which causes the reported symptom.

Best regards,
  Seb

-- 
Sebastien Vauban




reply via email to

[Prev in Thread] Current Thread [Next in Thread]