Achim Gratz writes:
> Thorsten Jolitz writes:
>> I do have my bad experiences with mixed installations, so the first
>> thing I do when I install or update Emacs is to trash the Org-mode that
>> comes with Emacs and replace it with a symlink to the git version.
>
> What you do doesn't work the w
Thorsten Jolitz writes:
> I do have my bad experiences with mixed installations, so the first
> thing I do when I install or update Emacs is to trash the Org-mode that
> comes with Emacs and replace it with a symlink to the git version.
What you do doesn't work the way you think it does, since yo
Thorsten Jolitz wrote:
> Nick Dokos writes:
>
> >> but nevertheless, opening an .org file gives me:
> >> File mode specification error:
> >> (void-function org-define-obsolete-function-alias)
> >>
> >
> > There is no such function in current org (either defined or used). The
> > remaining inst
Nick Dokos writes:
>> but nevertheless, opening an .org file gives me:
>> File mode specification error:
>> (void-function org-define-obsolete-function-alias)
>>
>
> There is no such function in current org (either defined or used). The
> remaining instance was deleted in this commit:
>
> ,
Thorsten Jolitz wrote:
> Eric Schulte writes:
>
> > Thorsten Jolitz writes:
> >
> >> Eric Schulte writes:
> >>
> >>> If you are using the starter-kit, then Org-mode is required as the first
> >>> step of your Emacs initialization. This is necessary so that the
> >>> `org-babel-load-file' fun
Eric Schulte writes:
> Thorsten Jolitz writes:
>
>> Eric Schulte writes:
>>
>>> If you are using the starter-kit, then Org-mode is required as the first
>>> step of your Emacs initialization. This is necessary so that the
>>> `org-babel-load-file' function can be used to load your customizatio
Thorsten Jolitz writes:
> Eric Schulte writes:
>
>> If you are using the starter-kit, then Org-mode is required as the first
>> step of your Emacs initialization. This is necessary so that the
>> `org-babel-load-file' function can be used to load your customization
>> from .org files. In this
Eric Schulte writes:
> If you are using the starter-kit, then Org-mode is required as the first
> step of your Emacs initialization. This is necessary so that the
> `org-babel-load-file' function can be used to load your customization
> from .org files. In this case the best (only) way to ensur
Thorsten Jolitz writes:
> Stelian Iancu writes:
>
>>> I just updated Org-mode from Git a few minutes ago, and, after having
>>> problems, deleted the repo and cloned it again, ran make and make
>>> autoloads, but still cannot load org.el (or start with my usual
>>> starter-kit customisations):
>
Stelian Iancu writes:
>> I just updated Org-mode from Git a few minutes ago, and, after having
>> problems, deleted the repo and cloned it again, ran make and make
>> autoloads, but still cannot load org.el (or start with my usual
>> starter-kit customisations):
>>
>
> [SNIP]
>
> Just my 2c: in
On Jan 13, 2013, at 11:08 PM, Thorsten Jolitz wrote:
> Achim Gratz writes:
>
>> Eric Schulte writes:
>>> Recently my Emacs start up fails when I (require 'org) because the
>>> function `org-load-noerror-mustsuffix' is undefined. I was able to fix
>>> this by checking out the version previous
Achim Gratz writes:
> Eric Schulte writes:
>> Recently my Emacs start up fails when I (require 'org) because the
>> function `org-load-noerror-mustsuffix' is undefined. I was able to fix
>> this by checking out the version previous to commit 5484a33b [1].
>
> Your Emacs loads an outdated org-mac
Bastien writes:
>> Please go back to the beginning of the thread and read about Eric's
>> problem, that's what the patch is trying to solve.
>
> Also, sorry to insist, but Eric bumped on a bug you introduced and
> committed just before the merge with Emacs emacs-24, which is bad.
Sorry, but there
Bastien writes:
>> In other words something like this:
>>
>> (require 'org-compat)
>> (require 'org-macs)
>> (add-to-list 'load-path "/home/org-mode/lisp")
>> (require 'org)
>
> Anybody can see this is wrong, and instead of letting users shoot
> themselves in the foot with a wrong setup, we should
Achim Gratz writes:
> Please go back to the beginning of the thread and read about Eric's
> problem, that's what the patch is trying to solve.
Also, sorry to insist, but Eric bumped on a bug you introduced and
committed just before the merge with Emacs emacs-24, which is bad.
What would help wo
> No, not at all. That's what reverting db7ece9fa2 does. And if you
> really want to flip off folks with strange Org installations instead of
> helping them survive, then leave out that third "t", i.e. just change
> that line to:
Please lower your tone.
I'm not "flipping off" anybody.
> In oth
Bastien writes:
> Also, the series rintroduces a warning because it moves
> `org-effort-durations'.
Yes, only in single-file compilation mode and it is completely
irrelevant to the problem at hand and can be fixed easily, so I opted to
get the code out to be tested and fix this later.
> Finally,
Thanks for the patch, it made me realize Org breaks Emacs coding
conventions by allowing advice in several places. I will work on
removing them.
Also, the series rintroduces a warning because it moves
`org-effort-durations'.
Finally, as far as I understand, you are arguing that users may want
to
Bastien writes:
> If you want to fix Emacs with respect to allowing loaddefs.el and
> org-loaddefs.el compression, please do.
There is nothing to fix in Emacs, it doesn't care if loaddefs is
compressed or not.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]
Achim Gratz writes:
> The problem is that for the previous discussion "(require 'org-macs)"
> was effectively a NOP because 'org-macs was already loaded from a
> different place. If you want to fix it, then that's where the effort
> should be directed (org-reload already does that and it's not dif
Achim Gratz writes:
> Bastien writes:
>> (load "org-loaddefs.el" t t t) will *not* load gzipped version of
>> org-loaddefs.el.
>
> That's what I was trying to tell you and I consider that a bug.
I don't.
>> Please point at one distribution that actually distributes gzipped
>> autoloads files li
Bastien writes:
> (load "org-loaddefs.el" t t t) will *not* load gzipped version of
> org-loaddefs.el.
That's what I was trying to tell you and I consider that a bug.
> Please point at one distribution that actually distributes gzipped
> autoloads files like loaddefs.el.
Why should I? People ha
Eric Schulte writes:
> Shouldn't this sort of discussion and development be taking place on
> emacs-dev and in non-org Emacs libraries.
Yes, it does.
--
Bastien
Achim Gratz writes:
> Bastien writes:
>> Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and
>> not ".elc" files, right? My question is: when is it necessary?
>
> The 'mustsuffix argument prevents consideration of the filename without
> the extensions listed in load-suffixes. I
Eric Schulte writes:
> These sounds like a Emacs-wide (or possibly find-library) issues, rather
> than anything specific to Org, outlining, agendas or plain text notes.
>
> Shouldn't this sort of discussion and development be taking place on
> emacs-dev and in non-org Emacs libraries.
I've already
Achim Gratz writes:
> Bastien writes:
>> Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and
>> not ".elc" files, right? My question is: when is it necessary?
>
> The 'mustsuffix argument prevents consideration of the filename without
> the extensions listed in load-suffixes. I
Bastien writes:
> Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and
> not ".elc" files, right? My question is: when is it necessary?
The 'mustsuffix argument prevents consideration of the filename without
the extensions listed in load-suffixes. In other words, when you are
try
Achim Gratz writes:
> Bastien writes:
>> There is this line at the end of org-loaddefs.el:
>>
>> ;; no-byte-compile: t
>>
>> So my understanding is that org-loaddefs.el is never compressed.
>
> Byte-compiled != compressed.
Yep, typo. But the 'mustsuffix trick is to force loading ".el" (and
not
Bastien writes:
> There is this line at the end of org-loaddefs.el:
>
> ;; no-byte-compile: t
>
> So my understanding is that org-loaddefs.el is never compressed.
Byte-compiled != compressed.
> Under which conditions is it compressed?
When calling gzip on it.
>> In particular, when there is ano
Achim Gratz writes:
> Also, this change again breaks installs where the autoloads file is
> compressed (that was the reason for introduction of the more complicated
> way to load this file that led to the introduction of the new
> macro).
There is this line at the end of org-loaddefs.el:
;; no-
Eric Schulte writes:
> My only suggestion would be that they include the following step.
>
> ;; emacs-lisp
> (require 'org)
> (org-reload)
These are both not necessary in the general case and should probably not
be attempted to be solved this way even in special circumstances.
I'll say it a
Bastien writes:
> Loading org-loaddefs.el through `org-load-noerror-mustsuffix' is
> asking for troubles. I removed this.
However, in a situation where this is indeed the problem, you actually
don't solve it and it will just appear slightly later.
Also, this change again breaks installs where
Hi Eric,
Eric Schulte writes:
> Great, thank you for running this to ground. After my last email I ran
> into the problem again, but didn't have the energy to continue
> debugging.
Yeah, I know how depressing this can be..
> To follow up on the instillation instructions. Those in the manual
Bastien writes:
> Hi Eric,
>
> actually, digging your problem further, I finally committed this
> patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=db7ece
>
Great, thank you for running this to ground. After my last email I ran
into the problem again, but didn't have the energy to cont
Hi Eric,
actually, digging your problem further, I finally committed this
patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=db7ece
Loading org-loaddefs.el through `org-load-noerror-mustsuffix' is
asking for troubles. I removed this.
Thanks for the time spent on this,
--
Bastien
Eric Schulte gmail.com> writes:
> Alright, after adding the autoload declaration to the above function,
> and running "make autoloads" in the checked out Org-mode directory, I am
> able to load org.el successfully. I just committed this change.
You are getting ahead of yourself, there is no need
Eric Schulte gmail.com> writes:
> > and where do you set load-path?
>
> No load path customization, just those two lines above are enough to
> cause the error.
How do you expect Emacs to recognize that you'll want to use a different Org?
> alright, starting with emacs -Q, evaluate the followin
Hi Eric,
Eric Schulte writes:
> Alright, after adding the autoload declaration to the above function,
> and running "make autoloads" in the checked out Org-mode directory, I am
> able to load org.el successfully. I just committed this change.
Are you sure adding ;;;###autoload was needed for t
Bastien writes:
> Hi Eric,
>
> Eric Schulte writes:
>
>> Retracted. This only works because,
>>
>> (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>> (require 'org)
>>
>> Does not in fact load up the newest version of Org-mode.
>
> How did you check?
>
> You don't have the error ab
Eric Schulte wrote:
> Eric Schulte writes:
>
> > Bastien writes:
> >
> >> Does your emacs fail if you simply point to the correct load path?
> >>
> >> I.e. a one-line init.el with this:
> >>
> >> (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
> >>
> >> ?
> >
> > Excellent, that doe
Eric Schulte wrote:
> alright, starting with emacs -Q, evaluate the following in your scratch
> buffer.
>
> (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>
> it may complain (void-function org-define-obsolete-function-alias), in
> which case evaluate the following in your scratch buffer
>
Eric Schulte wrote:
> I attempted to apply your suggestions to my init.el resulting in the
> following
>
>
> (add-hook 'after-init-hook
> `(lambda ()
> (require 'org)
> (setq features (remove 'org-macs features))
> (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
> (loa
> Retracted. This only works because,
>
> (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
> (require 'org)
>
> Does not in fact load up the newest version of Org-mode.
>
> I'm surprised I'm the only person experiencing this problem. Can anyone
> else reproduce this locally? To re-i
> Retracted. This only works because,
>
> (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
> (require 'org)
>
> Does not in fact load up the newest version of Org-mode.
>
> I'm surprised I'm the only person experiencing this problem. Can anyone
> else reproduce this locally? To re-i
Hi Eric,
Eric Schulte writes:
> Retracted. This only works because,
>
> (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
> (require 'org)
>
> Does not in fact load up the newest version of Org-mode.
How did you check?
You don't have the error about the missing function anymore, ri
Achim Gratz writes:
> Eric Schulte writes:
>> This is done I now have no Org packages in my ELPA. However I *still*
>> can't use any version of Org-mode post the 5484a33b commit. For the
>> simplest possible reproduction instructions, try the following.
>>
>> 1. mv your init.el to a backup loca
Eric Schulte writes:
> Bastien writes:
>
>> Does your emacs fail if you simply point to the correct load path?
>>
>> I.e. a one-line init.el with this:
>>
>> (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>>
>> ?
>
> Excellent, that does indeed work, I should have tried it much earli
Bastien writes:
> Does your emacs fail if you simply point to the correct load path?
>
> I.e. a one-line init.el with this:
>
> (add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
>
> ?
Excellent, that does indeed work, I should have tried it much earlier.
Sorry about the noise,
--
Eri
Eric Schulte writes:
> This is done I now have no Org packages in my ELPA. However I *still*
> can't use any version of Org-mode post the 5484a33b commit. For the
> simplest possible reproduction instructions, try the following.
>
> 1. mv your init.el to a backup locate
>
> 2. replace your init.e
Does your emacs fail if you simply point to the correct load path?
I.e. a one-line init.el with this:
(add-to-list 'load-path "~/.emacs.d/src/org-mode/lisp/")
?
--
Bastien
Hi Eric,
Eric Schulte writes:
> If this problem is specific to my situation I'm happy to ignore it until
> I can update my elpa version of Org-mode to a newer one. Alternately I
> could just remove my ELPA install of Org-mode, as it was only installed
> to answer questions on the mailing list,
Eric Schulte writes:
> Recently my Emacs start up fails when I (require 'org) because the
> function `org-load-noerror-mustsuffix' is undefined. I was able to fix
> this by checking out the version previous to commit 5484a33b [1].
Your Emacs loads an outdated org-macs.el. Additionally, you have
Bastien writes:
> Hi Eric,
>
> Eric Schulte writes:
>
>> If this problem is specific to my situation I'm happy to ignore it until
>> I can update my elpa version of Org-mode to a newer one. Alternately I
>> could just remove my ELPA install of Org-mode, as it was only installed
>> to answer que
Nick Dokos writes:
> Eric Schulte wrote:
>
>> Bastien writes:
>>
>> > Eric Schulte writes:
>> >
>> >> Even with the addition of that autoload statement I get the same error
>> >>
>> >> let: Symbol's function definition is void:
>> >> org-load-noerror-mustsuffix
>> >
>> > Do you have any O
Eric Schulte wrote:
> Bastien writes:
>
> > Eric Schulte writes:
> >
> >> Even with the addition of that autoload statement I get the same error
> >>
> >> let: Symbol's function definition is void:
> >> org-load-noerror-mustsuffix
> >
> > Do you have any Org function called before (require
Bastien writes:
> Eric Schulte writes:
>
>> Even with the addition of that autoload statement I get the same error
>>
>> let: Symbol's function definition is void:
>> org-load-noerror-mustsuffix
>
> Do you have any Org function called before (require 'org)?
>
> `org-load-noerror-mustsuffix'
Eric Schulte writes:
> Even with the addition of that autoload statement I get the same error
>
> let: Symbol's function definition is void:
> org-load-noerror-mustsuffix
Do you have any Org function called before (require 'org)?
`org-load-noerror-mustsuffix' is part of org-macs.el which is
Nope,
Even with the addition of that autoload statement I get the same error
let: Symbol's function definition is void: org-load-noerror-mustsuffix
Best,
Bastien writes:
> Hi Eric,
>
> Eric Schulte writes:
>
>> Recently my Emacs start up fails when I (require 'org) because the
>> function
Hi Eric,
Eric Schulte writes:
> Recently my Emacs start up fails when I (require 'org) because the
> function `org-load-noerror-mustsuffix' is undefined. I was able to fix
> this by checking out the version previous to commit 5484a33b [1].
Does this patch help?
diff --git a/lisp/org-macs.el b
Hi,
Recently my Emacs start up fails when I (require 'org) because the
function `org-load-noerror-mustsuffix' is undefined. I was able to fix
this by checking out the version previous to commit 5484a33b [1].
Best,
Footnotes:
[1] commit 5484a33b8d1382958095922bc9bc2bd6f1d9ffc6
Author: Achim Gr
60 matches
Mail list logo
