list-load-path-shadows

list-load-path-shadows

[Thomas S. Dye]

Aloha all,

I'm working to understand why my initialization files don't work if I
compile org from git, but do seem to work (that is, initialization runs
to completion) when I don't compile org from git.  Right now I've
installed org from git and have run make uncompiled.

Because mixed installations are common, I'm following the FAQ "Is my
Orgmode installation mixed?"

(org-version) looks good:
Org-mode version 7.9.1 (release_7.9.1-138-geeb5b9 @
/Users/dk/.emacs.d/src/org-mode/lisp/)

The FAQ advises that I go through the output of list-load-path-shadows
line by line to get hints, but fails to mention what might qualify as a
hint.  So, I'm coming to the list to check if any of the shadow patterns
I'm seeing might be hints.

I see that 110 Emacs Lisp load-path shadowings were found.  

108 of the shadowings are cases where a file in
~/.emacs.d/src/org-mode/lisp (my home for the git version of org mode)
hides a file of the same name in
/Applications/Emacs.app/Contents/Resources/lisp/org/.  I think these 108
shadowings are the right thing, and that they are not hints that
something is wrong.  Is 108 shadowings the correct number for a normal
org mode installation nowadays?

The other two are different.

The first one is:
/Users/dk/.emacs.d/custom hides
/Applications/Emacs.app/Contents/Resources/lisp/custom

Here, the file created by the emacs Customize interface is on the
load-path and shadows something completely different (and important?),
though not part of org mode.  Should I do something to have the emacs
Customize interface put the file somewhere off the load-path?

The second one is: 
/Users/dk/.emacs.d/src/org-mode/.dir-locals hides
/Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals

I keep hoping gnus will heal itself and stop hanging emacs--could this
shadowing be causing problems?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: list-load-path-shadows

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Aloha all,
> 
> I'm working to understand why my initialization files don't work if I
> compile org from git, but do seem to work (that is, initialization runs
> to completion) when I don't compile org from git.  Right now I've
> installed org from git and have run make uncompiled.
> 

It might be a good idea to run with --debug-init in the compiled case
and get a backtrace.

I doubt the shadowing you discuss below makes a difference here (but
I could be wrong).

Nick

> Because mixed installations are common, I'm following the FAQ "Is my
> Orgmode installation mixed?"
> 
> (org-version) looks good:
> Org-mode version 7.9.1 (release_7.9.1-138-geeb5b9 @
> /Users/dk/.emacs.d/src/org-mode/lisp/)
> 
> The FAQ advises that I go through the output of list-load-path-shadows
> line by line to get hints, but fails to mention what might qualify as a
> hint.  So, I'm coming to the list to check if any of the shadow patterns
> I'm seeing might be hints.
> 
> I see that 110 Emacs Lisp load-path shadowings were found.  
> 
> 108 of the shadowings are cases where a file in
> ~/.emacs.d/src/org-mode/lisp (my home for the git version of org mode)
> hides a file of the same name in
> /Applications/Emacs.app/Contents/Resources/lisp/org/.  I think these 108
> shadowings are the right thing, and that they are not hints that
> something is wrong.  Is 108 shadowings the correct number for a normal
> org mode installation nowadays?
> 
> The other two are different.
> 
> The first one is:
> /Users/dk/.emacs.d/custom hides
> /Applications/Emacs.app/Contents/Resources/lisp/custom
> 
> Here, the file created by the emacs Customize interface is on the
> load-path and shadows something completely different (and important?),
> though not part of org mode.  Should I do something to have the emacs
> Customize interface put the file somewhere off the load-path?
> 
> The second one is: 
> /Users/dk/.emacs.d/src/org-mode/.dir-locals hides
> /Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals
> 
> I keep hoping gnus will heal itself and stop hanging emacs--could this
> shadowing be causing problems?
> 
> All the best,
> Tom
> 
> -- 
> Thomas S. Dye
> http://www.tsdye.com
> 

Re: list-load-path-shadows

[Thomas S. Dye]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> Aloha all,
>> 
>> I'm working to understand why my initialization files don't work if I
>> compile org from git, but do seem to work (that is, initialization runs
>> to completion) when I don't compile org from git.  Right now I've
>> installed org from git and have run make uncompiled.
>> 
>
> It might be a good idea to run with --debug-init in the compiled case
> and get a backtrace.

Hi Nick,

After make compile, starting emacs --debug-init yields this backtrace:

Debugger entered--Lisp error: (void-function org-find-library-dir)
  (org-find-library-dir "org")
  (file-name-directory (org-find-library-dir "org"))
  (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))
  (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))
  (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))))
  (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))
  (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))))))
  eval((expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))))
  custom-initialize-reset(org-ditaa-jar-path (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))))
  custom-declare-variable(org-ditaa-jar-path (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))) "Path to the ditaa jar executable." :group org-babel :type string)

AFAICT, org-find-library-dir is a macro defined in org-compat.el.  Not
sure why compiling would make it disappear.  Initialization runs to
completion when org isn't compiled.

Tom

>
> I doubt the shadowing you discuss below makes a difference here (but
> I could be wrong).
>
> Nick
>
>> Because mixed installations are common, I'm following the FAQ "Is my
>> Orgmode installation mixed?"
>> 
>> (org-version) looks good:
>> Org-mode version 7.9.1 (release_7.9.1-138-geeb5b9 @
>> /Users/dk/.emacs.d/src/org-mode/lisp/)
>> 
>> The FAQ advises that I go through the output of list-load-path-shadows
>> line by line to get hints, but fails to mention what might qualify as a
>> hint.  So, I'm coming to the list to check if any of the shadow patterns
>> I'm seeing might be hints.
>> 
>> I see that 110 Emacs Lisp load-path shadowings were found.  
>> 
>> 108 of the shadowings are cases where a file in
>> ~/.emacs.d/src/org-mode/lisp (my home for the git version of org mode)
>> hides a file of the same name in
>> /Applications/Emacs.app/Contents/Resources/lisp/org/.  I think these 108
>> shadowings are the right thing, and that they are not hints that
>> something is wrong.  Is 108 shadowings the correct number for a normal
>> org mode installation nowadays?
>> 
>> The other two are different.
>> 
>> The first one is:
>> /Users/dk/.emacs.d/custom hides
>> /Applications/Emacs.app/Contents/Resources/lisp/custom
>> 
>> Here, the file created by the emacs Customize interface is on the
>> load-path and shadows something completely different (and important?),
>> though not part of org mode.  Should I do something to have the emacs
>> Customize interface put the file somewhere off the load-path?
>> 
>> The second one is: 
>> /Users/dk/.emacs.d/src/org-mode/.dir-locals hides
>> /Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals
>> 
>> I keep hoping gnus will heal itself and stop hanging emacs--could this
>> shadowing be causing problems?
>> 
>> All the best,
>> Tom
>> 
>> -- 
>> Thomas S. Dye
>> http://www.tsdye.com
>> 
>
>

-- 
Thomas S. Dye
http://www.tsdye.com

Re: list-load-path-shadows

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >
> >> Aloha all,
> >> 
> >> I'm working to understand why my initialization files don't work if I
> >> compile org from git, but do seem to work (that is, initialization runs
> >> to completion) when I don't compile org from git.  Right now I've
> >> installed org from git and have run make uncompiled.
> >> 
> >
> > It might be a good idea to run with --debug-init in the compiled case
> > and get a backtrace.
> 
> Hi Nick,
> 
> After make compile, starting emacs --debug-init yields this backtrace:
> 
> Debugger entered--Lisp error: (void-function org-find-library-dir)
>   (org-find-library-dir "org")
>   (file-name-directory (org-find-library-dir "org"))
>   (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))
>   (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))
>   (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))))
>   (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))
>   (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))))))
>   eval((expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))))
>   custom-initialize-reset(org-ditaa-jar-path (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))))
>   custom-declare-variable(org-ditaa-jar-path (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))) "Path to the ditaa jar executable." :group org-babel :type string)
> 
> AFAICT, org-find-library-dir is a macro defined in org-compat.el.  Not
> sure why compiling would make it disappear.  Initialization runs to
> completion when org isn't compiled.
> 
> > I doubt the shadowing you discuss below makes a difference here (but
> > I could be wrong).
> >

Looks like I was wrong :-) The custom shadowing seems to play a role.
Just guessing, it's probably a chicken-and-egg situation: you load the
custom file before org gets initialized and there is no autoload that
manages to get the macro defined before it is used.

One way to break the loop is to not use the macro in your custom file:
replace it by its definition. Another way is to delete the customization
of org-ditaa-jar-path from the custom file and include it after org gets
initialized. Both of these are to be considered workaround hacks than
solutions, but it's hard to propose a solution without knowing exactly
what the problem is.

If you still can't make it work, please post the initialization file(s)
and the two custom files and maybe somebody can figure out something.

HTH,
Nick

Re: list-load-path-shadows

[Thomas S. Dye]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>> 
>> > Thomas S. Dye <tsd@tsdye.com> wrote:
>> >
>> >> Aloha all,
>> >> 
>> >> I'm working to understand why my initialization files don't work if I
>> >> compile org from git, but do seem to work (that is, initialization runs
>> >> to completion) when I don't compile org from git.  Right now I've
>> >> installed org from git and have run make uncompiled.
>> >> 
>> >
>> > It might be a good idea to run with --debug-init in the compiled case
>> > and get a backtrace.
>> 
>> Hi Nick,
>> 
>> After make compile, starting emacs --debug-init yields this backtrace:
>> 
>> Debugger entered--Lisp error: (void-function org-find-library-dir)
>>   (org-find-library-dir "org")
>>   (file-name-directory (org-find-library-dir "org"))
>>   (expand-file-name "../contrib" (file-name-directory
>> (org-find-library-dir "org")))
>>   (file-name-as-directory (expand-file-name "../contrib"
>> (file-name-directory (org-find-library-dir "org"))))
>>   (expand-file-name "scripts" (file-name-as-directory
>> (expand-file-name "../contrib" (file-name-directory
>> (org-find-library-dir "org")))))
>>   (file-name-as-directory (expand-file-name "scripts"
>> (file-name-as-directory (expand-file-name "../contrib"
>> (file-name-directory (org-find-library-dir "org"))))))
>>   (expand-file-name "ditaa.jar" (file-name-as-directory
>> (expand-file-name "scripts" (file-name-as-directory
>> (expand-file-name "../contrib" (file-name-directory
>> (org-find-library-dir "org")))))))
>>   eval((expand-file-name "ditaa.jar" (file-name-as-directory
>> (expand-file-name "scripts" (file-name-as-directory
>> (expand-file-name "../contrib" (file-name-directory
>> (org-find-library-dir "org"))))))))
>>   custom-initialize-reset(org-ditaa-jar-path (expand-file-name
>> "ditaa.jar" (file-name-as-directory (expand-file-name "scripts"
>> (file-name-as-directory (expand-file-name "../contrib"
>> (file-name-directory (org-find-library-dir "org"))))))))
>>   custom-declare-variable(org-ditaa-jar-path (expand-file-name
>> "ditaa.jar" (file-name-as-directory (expand-file-name "scripts"
>> (file-name-as-directory (expand-file-name "../contrib"
>> (file-name-directory (org-find-library-dir "org"))))))) "Path to the
>> ditaa jar executable." :group org-babel :type string)
>> 
>> AFAICT, org-find-library-dir is a macro defined in org-compat.el.  Not
>> sure why compiling would make it disappear.  Initialization runs to
>> completion when org isn't compiled.
>> 
>> > I doubt the shadowing you discuss below makes a difference here (but
>> > I could be wrong).
>> >
>
> Looks like I was wrong :-) The custom shadowing seems to play a role.
> Just guessing, it's probably a chicken-and-egg situation: you load the
> custom file before org gets initialized and there is no autoload that
> manages to get the macro defined before it is used.
>
> One way to break the loop is to not use the macro in your custom file:
> replace it by its definition. Another way is to delete the customization
> of org-ditaa-jar-path from the custom file and include it after org gets
> initialized. Both of these are to be considered workaround hacks than
> solutions, but it's hard to propose a solution without knowing exactly
> what the problem is.
>
> If you still can't make it work, please post the initialization file(s)
> and the two custom files and maybe somebody can figure out something.
>
> HTH,
> Nick

Hi Nick,

The initialization error was coming when one of my files was being
evaluated.  If I don't require org-latex, the compiled version of org
will initialize.

*** OFF Require org-latex
#+begin_src emacs-lisp :tangle no
  (require 'org-latex)
#+end_src

However, evaluating (require 'org-latex) in *scratch* yields this
familiar error:

Debugger entered--Lisp error: (void-function org-find-library-dir)
  (org-find-library-dir "org")
  (file-name-directory (org-find-library-dir "org"))
  (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))
  (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))
  (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))))
  (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))
  (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org")))))))
  eval((expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))))
  custom-initialize-reset(org-ditaa-jar-path (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))))
  custom-declare-variable(org-ditaa-jar-path (expand-file-name "ditaa.jar" (file-name-as-directory (expand-file-name "scripts" (file-name-as-directory (expand-file-name "../contrib" (file-name-directory (org-find-library-dir "org"))))))) "Path to the ditaa jar executable." :group org-babel :type string)
  require(org-exp-blocks)
  byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\207" [require org org-macs org-agenda org-exp-blocks ob-exp org-src] 2)
  require(org-exp)
  byte-code("\301\302!\210\301\303!\210\301\304!\210\301\305!\210\301\306!\210\307\bB\310\307!\204#\311\307\312\"\210\313\bB\310\313!\2042\311\313\312\"\210\314\bB\310\314!\204A\311\314\312\"\210\315\bB\310\315!\204P\311\315\312\"\210\316\bB\310\316!\204_\311\316\312\"\210\317\bB\310\317!\204n\311\317\312\"\210\320\bB\310\320!\204}\311\320\312\"\210\321\bB\310\321!\204\214\311\321\312\"\210\322\bB\310\322!\204\233\311\322\312\"\210\323\bB\310\323!\204\252\311\323\312\"\210\324\bB\310\324!\204\271\311\324\312\"\210\325\bB\310\325!\204\310\311\325\326\"\210\312\207" [current-load-list require footnote org org-exp org-macs org-beamer org-export-latex-class default-boundp set-default nil org-export-latex-class-options org-export-latex-header org-export-latex-append-header org-export-latex-options-plist org-export-latex-todo-keywords-1 org-export-latex-complex-heading-re org-export-latex-not-done-keywords org-export-latex-done-keywords org-export-latex-display-custom-times org-export-latex-all-targets-re org-export-latex-add-level 0] 3)
  require(org-latex)
  eval((require (quote org-latex)) nil)
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)

Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: list-load-path-shadows

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> The initialization error was coming when one of my files was being
> evaluated.  If I don't require org-latex, the compiled version of org
> will initialize.
> 
> *** OFF Require org-latex
> #+begin_src emacs-lisp :tangle no
>   (require 'org-latex)
> #+end_src
> 

That's not what the previous backtrace showed though: the ditaa path
calculation was directly implicated.

In any case, the above shouldn't happen as long as you have done
``make autoloads'' or equivalent and 

   (require 'org-install)

beforehand, and in fact it does not happen in my case:

  emacs -q -l /path/to/minimal/.emacs

with the following minimal .emacs, starts up without error:

--8<---------------cut here---------------start------------->8---
;;; -*- mode: emacs-lisp -*-
;;; constant part
(add-to-list 'load-path (expand-file-name "~/src/emacs/org/org-mode/lisp"))
(add-to-list 'load-path (expand-file-name "~/src/emacs/org/org-mode/contrib/lisp"))

(add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))

(require 'org-install)

(setq debug-on-error t)
(setq debug-on-quit t)
(setq eval-expression-print-length nil)
(setq eval-expression-print-level nil)

(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-ca" 'org-agenda)

(require 'org-latex)
--8<---------------cut here---------------end--------------->8---


OTOH, even if I leave out the (require 'org-install), I get no error
(and that's after removing the org that came with emacs and making sure
that I have compiled everything), so I'm a bit baffled right now.

Nick

Re: list-load-path-shadows

[Thomas S. Dye]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> The initialization error was coming when one of my files was being
>> evaluated.  If I don't require org-latex, the compiled version of org
>> will initialize.
>> 
>> *** OFF Require org-latex
>> #+begin_src emacs-lisp :tangle no
>>   (require 'org-latex)
>> #+end_src
>> 
>
> That's not what the previous backtrace showed though: the ditaa path
> calculation was directly implicated.
>
> In any case, the above shouldn't happen as long as you have done
> ``make autoloads'' or equivalent and 
>
>    (require 'org-install)
>
> beforehand, and in fact it does not happen in my case:
>
>   emacs -q -l /path/to/minimal/.emacs
>
> with the following minimal .emacs, starts up without error:
>
> ;;; -*- mode: emacs-lisp -*-
> ;;; constant part
> (add-to-list 'load-path (expand-file-name "~/src/emacs/org/org-mode/lisp"))
> (add-to-list 'load-path (expand-file-name "~/src/emacs/org/org-mode/contrib/lisp"))
>
> (add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))
>
> (require 'org-install)
>
> (setq debug-on-error t)
> (setq debug-on-quit t)
> (setq eval-expression-print-length nil)
> (setq eval-expression-print-level nil)
>
> (global-set-key "\C-cl" 'org-store-link)
> (global-set-key "\C-ca" 'org-agenda)
>
> (require 'org-latex)
>
>
> OTOH, even if I leave out the (require 'org-install), I get no error
> (and that's after removing the org that came with emacs and making sure
> that I have compiled everything), so I'm a bit baffled right now.
>
> Nick
>
>
Hmm, after putting your minimal .emacs (suitably localized) in ~/temp,
emacs -Q -l /Users/dk/temp/.emacs launches emacs and opens the minimal
.emacs file for editing, but apparently doesn't source it.  M-x
locate-library RET org RET points to the org that ships with my emacs,
rather than to the one indicated in the minimal .emacs.

Following some advice on EmacsWiki, I have this in .bashrc:

alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs'
alias emacsclient='/Applications/Emacs.app/Contents/MacOS/bin/emacsclient'

Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: list-load-path-shadows

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Hmm, after putting your minimal .emacs (suitably localized) in ~/temp,
> emacs -Q -l /Users/dk/temp/.emacs launches emacs and opens the minimal
> .emacs file for editing, but apparently doesn't source it.  M-x
> locate-library RET org RET points to the org that ships with my emacs,
> rather than to the one indicated in the minimal .emacs.
> 
> Following some advice on EmacsWiki, I have this in .bashrc:
> 
> alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs'
> alias emacsclient='/Applications/Emacs.app/Contents/MacOS/bin/emacsclient'
> 

What happens if you bypass the alias?

/Applications/Emacs.app/Contents/MacOS/Emacs -Q -l /Users/dk/temp/.emacs

If it still doesn't work, I'll give up: MacOS emacs seems to be a very
different beast from any emacs I know.

Nick

Re: list-load-path-shadows

[Thomas S. Dye]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> Hmm, after putting your minimal .emacs (suitably localized) in ~/temp,
>> emacs -Q -l /Users/dk/temp/.emacs launches emacs and opens the minimal
>> .emacs file for editing, but apparently doesn't source it.  M-x
>> locate-library RET org RET points to the org that ships with my emacs,
>> rather than to the one indicated in the minimal .emacs.
>> 
>> Following some advice on EmacsWiki, I have this in .bashrc:
>> 
>> alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs'
>> alias emacsclient='/Applications/Emacs.app/Contents/MacOS/bin/emacsclient'
>> 
>
> What happens if you bypass the alias?
>
> /Applications/Emacs.app/Contents/MacOS/Emacs -Q -l /Users/dk/temp/.emacs
>
> If it still doesn't work, I'll give up: MacOS emacs seems to be a very
> different beast from any emacs I know.
>
> Nick

Hi Nick,

Apparently a very different beast :(

Thanks for your help.  I probably wouldn't have thought to wonder
whether my emacs was the culprit.  I guess I'll try a different
installation to see what shakes out.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: list-load-path-shadows

[Nick Dokos]

Thomas S. Dye <tsd@tsdye.com> wrote:

> Nick Dokos <nicholas.dokos@hp.com> writes:
> 
> > Thomas S. Dye <tsd@tsdye.com> wrote:
> >
> >> Hmm, after putting your minimal .emacs (suitably localized) in ~/temp,
> >> emacs -Q -l /Users/dk/temp/.emacs launches emacs and opens the minimal
> >> .emacs file for editing, but apparently doesn't source it.  M-x
> >> locate-library RET org RET points to the org that ships with my emacs,
> >> rather than to the one indicated in the minimal .emacs.
> >> 
> >> Following some advice on EmacsWiki, I have this in .bashrc:
> >> 
> >> alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs'
> >> alias emacsclient='/Applications/Emacs.app/Contents/MacOS/bin/emacsclient'
> >> 
> >
> > What happens if you bypass the alias?
> >
> > 
> >
> > If it still doesn't work, I'll give up: MacOS emacs seems to be a very
> > different beast from any emacs I know.
> >
> > Nick
> 
> Hi Nick,
> 
> Apparently a very different beast :(
> 
One more attempt: do long options work?

/Applications/Emacs.app/Contents/MacOS/Emacs --quick --load=/Users/dk/temp/.emacs

Nick

> Thanks for your help.  I probably wouldn't have thought to wonder
> whether my emacs was the culprit.  I guess I'll try a different
> installation to see what shakes out.
> 

Re: list-load-path-shadows

[Thomas S. Dye]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Thomas S. Dye <tsd@tsdye.com> wrote:
>
>> Nick Dokos <nicholas.dokos@hp.com> writes:
>> 
>> > Thomas S. Dye <tsd@tsdye.com> wrote:
>> >
>> >> Hmm, after putting your minimal .emacs (suitably localized) in ~/temp,
>> >> emacs -Q -l /Users/dk/temp/.emacs launches emacs and opens the minimal
>> >> .emacs file for editing, but apparently doesn't source it.  M-x
>> >> locate-library RET org RET points to the org that ships with my emacs,
>> >> rather than to the one indicated in the minimal .emacs.
>> >> 
>> >> Following some advice on EmacsWiki, I have this in .bashrc:
>> >> 
>> >> alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs'
>> >> alias emacsclient='/Applications/Emacs.app/Contents/MacOS/bin/emacsclient'
>> >> 
>> >
>> > What happens if you bypass the alias?
>> >
>> > 
>> >
>> > If it still doesn't work, I'll give up: MacOS emacs seems to be a very
>> > different beast from any emacs I know.
>> >
>> > Nick
>> 
>> Hi Nick,
>> 
>> Apparently a very different beast :(
>> 
> One more attempt: do long options work?
>
> /Applications/Emacs.app/Contents/MacOS/Emacs --quick
> --load=/Users/dk/temp/.emacs

Hi Nick,

Yes, long options do work, even with the alias.

emacs starts up, skips my initialization files, and loads the minimal
.emacs.  M-x locate-library RET org-latex RET points to the org
identified in the minimal .emacs.

I guess this means that all is well on the org end :)  And that my old
initialization files didn't make the upgrade to emacs 24 and the
emacs 24 starter kit :(

Thanks for all your help.

Tom

-- 
Thomas S. Dye
http://www.tsdye.com