[O] bug#10125: RFE: require and load-path-shadowing

[Achim Gratz]

Glenn Morris writes:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125#50
>
>Turns out I was looking for invocation-directory and invocation-name.

Indeed, thanks.  So using your earlier patch as a template, this should
be good for emacs-24:

--8<---cut here---start->8---
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 6059f03..df194b8 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -632,11 +632,20 @@ untar into a directory named DIR; otherwise, signal an 
error."
   "Generate autoloads and do byte-compilation for package named NAME.
 PKG-DIR is the name of the package directory."
   (package-generate-autoloads name pkg-dir)
-  (let ((load-path (cons pkg-dir load-path)))
-;; We must load the autoloads file before byte compiling, in
-;; case there are magic cookies to set up non-trivial paths.
-(load (expand-file-name (concat name "-autoloads") pkg-dir) nil t)
-(byte-recompile-directory pkg-dir 0 t)))
+  (with-current-buffer (get-buffer-create "*package-compile*")
+(goto-char (point-max))
+(pop-to-buffer (current-buffer))
+(or (zerop (call-process
+   (concat invocation-directory invocation-name)
+   nil t t "--batch" "-Q" "--eval"
+   (format
+"(let ((pkg-dir \"%s\")(name \"%s\"))
+(progn (setq load-path (cons pkg-dir load-path))
+(load (expand-file-name (concat name \"-autoloads\") 
pkg-dir) nil t)
+(batch-byte-recompile-directory 0)))"
+pkg-dir name)
+   pkg-dir))
+   (error "Compiling the package gave an error"
 
 (defun package--write-file-no-coding (file-name)
   (let ((buffer-file-coding-system 'no-conversion))
--8<---cut here---end--->8---

I've confirmed that Emacs 24.2 fails to install current Org from ELPA
without that patch when trying to install after having opened an Org
file.  It installs Org correctly in that same situation with the patch
that does the package compilation in an external Emacs process.


Regards
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

[O] colorg: Protocol [was: Re: Rudel - Real-Time collaborative editing of Org-Mode files]

[François Pinard]

François Pinard  writes:

> So, inventing a protocol is still an avenue which I naively seek, and
> for which I dared giving some thought recently, trying to stay on the
> side of simplicity.

Here is a stab at a simple protocol, which I documented in:

   https://github.com/pinard/ColOrg/wiki/Protocol

I have the start of colorg.el, and now intend to write the skeleton of a
server.  Before committing them, I'll stretch both enough so they speak
to one another.  Then we will have a sandbox to play with. :-)

François

Re: [O] habits don't get re-scheduled

[Karl Voit]

* Bastien  wrote:
> Hi Karl,

Hi!

> Karl Voit  writes:
>
>> I bisected this issue. It resulted in:
>
> I should have fixed this now, please let me know!

Fixed, thank you very much - once again! :-)

-- 
Karl Voit

[O] bug#10125: RFE: require and load-path-shadowing

[Glenn Morris]

Stefan Monnier wrote:

>> IOW, do you expect the byte-compile instances to be different in any
>> way from a fresh Emacs session invoked from the shell as "emacs -Q"?
>
> Yes, because the current Emacs may be a different executable than the
> one the shell would run in response to "emacs -Q".

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125#50

   Turns out I was looking for invocation-directory and invocation-name.

If you want to worry about wacky things like a new Emacs having been
installed on top of the old in the meantime, more power to you.

[O] bug#10125: RFE: require and load-path-shadowing

[Eli Zaretskii]

> From: Achim Gratz 
> Date: Sat, 12 Jan 2013 18:01:36 +0100
> 
> Eli Zaretskii writes:
> >> > IOW, do you expect the byte-compile instances to be different in any
> >> > way from a fresh Emacs session invoked from the shell as "emacs -Q"?
> >> 
> >> Yes, because the current Emacs may be a different executable than the
> >> one the shell would run in response to "emacs -Q".
> >
> > And if we make sure the same executable is run (easy on Windows)?  Are
> > there any other differences?
> 
> There may have been changes in the way Emacs starts up in the meantime,
> since we're considering the case where new packages get installed.
> Starting Emacs with "-Q" shouldn't be affected by this, but there's no
> guarantee (yes, this is a fringe case).

Sorry, I don't follow: new packages can only affect "emacs -Q" if you
re-dump Emacs in between.  Am I missing something?

[O] Break of two weeks

[Bastien]

Hi folks,

I'm taking a break of two weeks.

All best,

-- 
 Bastien

[O] bug#10125: RFE: require and load-path-shadowing

[Bastien]

Stefan Monnier  writes:

>> In that case, isn't it enough to call (package-initialize) before
>> any Org configuration?
>
> Here's the scenario:
>
> start Emacs
> use Org
> use package.el to install a newer version of Org

I see, thanks.

-- 
 Bastien

Re: [O] [PATCH] Change references to "~/.emacs.d" into `user-emacs-directory' ?

[Bastien]

Achim Gratz  writes:

> This introduces a regression, since XEmacs doesn't have that variable.
> This patch fixes it (apply on master):

Applied, thanks.

-- 
 Bastien

[O] bug#10125: RFE: require and load-path-shadowing

[Achim Gratz]

Eli Zaretskii writes:
>> > IOW, do you expect the byte-compile instances to be different in any
>> > way from a fresh Emacs session invoked from the shell as "emacs -Q"?
>> 
>> Yes, because the current Emacs may be a different executable than the
>> one the shell would run in response to "emacs -Q".
>
> And if we make sure the same executable is run (easy on Windows)?  Are
> there any other differences?

There may have been changes in the way Emacs starts up in the meantime,
since we're considering the case where new packages get installed.
Starting Emacs with "-Q" shouldn't be affected by this, but there's no
guarantee (yes, this is a fringe case).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [O] [PATCH] Change references to "~/.emacs.d" into `user-emacs-directory' ?

[Achim Gratz]

Bastien writes:
>> Not sure if this is of any importance, but since the variable
>> user-emacs-directory (a defconst) exists, maybe org-mode could use it
>> instead of "~/.emacs.d". It seems only relevant for MS-DOS systems,
>> though.
>
> Applied, thanks.

This introduces a regression, since XEmacs doesn't have that variable.
This patch fixes it (apply on master):

>From 59d70e47484db7cdebd9c8ac0fe2124cbe7db4b0 Mon Sep 17 00:00:00 2001
From: Achim Gratz 
Date: Sat, 12 Jan 2013 12:06:20 +0100
Subject: [PATCH] Compatibility: XEmacs does not have user-emacs-directory, use
 user-init-directory instead
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-compat.el (user-emacs-directory): If not bound, define as an alias to
  `user-init-directory´ so that XEmacs continues to be happy with Org.
---
 lisp/org-compat.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 687b81f..2d200b7 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -113,6 +113,11 @@ (defun org-version-check (version feature level)
 
  Emacs/XEmacs compatibility
 
+(eval-and-compile
+  (when (and (not (boundp 'user-emacs-directory))
+	 (boundp 'user-init-directory))
+(defvaralias 'user-emacs-directory 'user-init-directory)))
+
 ;; Keys
 (defconst org-xemacs-key-equivalents
   '(([mouse-1] . [button1])
-- 
1.8.1



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

[O] bug#10125: RFE: require and load-path-shadowing

[Achim Gratz]

Stefan Monnier writes:
>> In that case, isn't it enough to call (package-initialize) before
>> any Org configuration?
>
> Here's the scenario:
>
> start Emacs
> use Org
> use package.el to install a newer version of Org

Exactly.  Thanks for putting it so succinctly.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

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 is no bug.  The change only switches the failure mode
from "fall over some time later" to "stop with an error now" for the
wrong init sequence that Eric tried.  Also:

Bastien writes:
> Please feel free to apply those patch, thanks a lot.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

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 educate them to
> use a correct one like

Yes, if it's in four consecutive lines its easy to see.  The cold truth
is that the first two lines may not be visible to the user at all.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

[O] bug#10125: RFE: require and load-path-shadowing

[Stefan Monnier]

> In that case, isn't it enough to call (package-initialize) before
> any Org configuration?

Here's the scenario:

start Emacs
use Org
use package.el to install a newer version of Org


Stefan

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

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 would be a flag like "[exp]" on patches that are
really just experimental and for exploration only -- like the ones
you just posted.

-- 
 Bastien

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

> 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 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 educate them to
use a correct one like

(add-to-list 'load-path "/home/org-mode/lisp")
(require 'org)

which shouldn't be that hard.

> will result in a correctly loaded Org with the patch, but yield either a
> not-correctly working Org (silently wrong and producing strange results
> that nobody can reproduce) or a failure to load Org at all (you get an
> error at least) without it.

I'm fine with not fixing this right now.

> It is also an experiment to determine if Emacs should do something like
> this (by default or as an option) and how to best implement it.  Even if
> it eventually moved into Emacs however, Org would still have to
> implement it as a workaround for older Emacsen that don't have it.

Again, I'm fine with any experiment that can be done on Emacs side so
that Emacs autoloads are always correct.  But I won't allow a patch
that advise `require' in Org for now.

Thanks,

-- 
 Bastien

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

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, as far as I understand, you are arguing that users may want
> to compress their Org files, and that (load "org-loaddefs.el") will
> fail if they do, and that's why they need this patch.

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:

(load "org-loaddefs" 'noerror 'nomessage)

That will wreak havoc for someone who managed to pull all stops and
byte-compile org-loaddefs anyway, but any sane setup will work as
intended.

> If the additional complexity is just for this, I'm not convinced by
> the patch.  If it fixes something else, please let me know.

Please go back to the beginning of the thread and read about Eric's
problem, that's what the patch is trying to solve.  Based on the
comments in bug#10125 by Jambunathan, borked setups with partly loaded
Org versions are much more common than I would have thought.

In other words something like this:

--8<---cut here---start->8---
(require 'org-compat)
(require 'org-macs)
(add-to-list 'load-path "/home/org-mode/lisp")
(require 'org)
--8<---cut here---end--->8---

will result in a correctly loaded Org with the patch, but yield either a
not-correctly working Org (silently wrong and producing strange results
that nobody can reproduce) or a failure to load Org at all (you get an
error at least) without it.

It is also an experiment to determine if Emacs should do something like
this (by default or as an option) and how to best implement it.  Even if
it eventually moved into Emacs however, Org would still have to
implement it as a workaround for older Emacsen that don't have it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

[O] [PATCH] exiting source block edit without change should not change buffer-modified sttatus

[Le Wang]

Currently when I press "C-c '", and immediately exit with "C-c '", the
org buffer's modified flag is set, even though I didn't change
anything.

Code changes with testcases included.  I'm not sure if this can be
made generic for other types of special edit.

-- 
Le


0001-add-tests-for-round-trip-source-block-without-change.patch
Description: Binary data


0002-Fix-unmodified-source-blocking-editing-setting-buffe.patch
Description: Binary data

[O] building org on OSX for aquamacs?

[Filippo Salustri]

Anyone got any advice viz building org for aquamacs on OSX?
Aquamacs hasn't got -batch, so I can't do the org-only build.
/fas

-- 
\V/_
Filippo A. Salustri, Ph.D., P.Eng.
Email: salus...@ryerson.ca
http://deseng.ryerson.ca/~fil/

Re: [O] Rudel - Real-Time collaborative editing of Org-Mode files

[François Pinard]

Torben Hoffmann  writes:

> Not sure if it would be speedy enough, but gitit [...]

Thanks for the pointer! :-)

> Inventing a protocol to deal with synchronisation is not trivial, so a
> good starting point might be gitit or raw git with the intention of
> learning about what the real issues are before creating a system from
> scratch to solve what might not be the right problem to solve.

I tried to see a bit how to get hold on a synchronization protocol which
would be easy to use, and have been overwhelmed so far by the complexity
of the specifications, and also the implementations I quickly looked at.
I really want something simple enough for me to grasp (you know, I've
short limits!), and would be rather willing and ready to compromise on
the generality or speed, in the sake of simplicity.

So, inventing a protocol is still an avenue which I naively seek, and
for which I dared giving some thought recently, trying to stay on the
side of simplicity.

> I have not used org enough to be able to judge these issues, but I
> would like to have a good multi-user solution since org seems to be
> one of the better ways to collaborate.

Sigh!  Yes! :-)

François

Re: [O] [new exporter] adhere org-export-date-timestamp-format?

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> The attached patch moves them into org.el, with an org-timestamp-
> prefix.

Looks, good, please go ahead.

> Though, I think I have to withdraw my proposal about using #+DATE: value
> as a time format string. Indeed, date value, along with any document
> property, is parsed, which defeats the purpose of using it as a format
> string.
>
> We can still implement a convenient macro to handle timestamps in date
> keyword.
>
> What do you think?

Up to whatever you find more practical.

Thanks!

-- 
 Bastien

Re: [O] Custom Agenda with Tag search for multiple items ( \\ Between search terms) fails push

[Bastien]

Hi Jeff,

Jeff Myer  writes:

> I have a custom agenda item in my .emacs file that is for a Tags
> search for multiple items as follows (not the whole thing just the
> bit that is giving me trouble): 
>
> "E" "Items Tagged for the Engineering Staff" tags "{Allen\\|Dave\\|
> JimD\\|Heming\\|Paul\\|EdM}-TODO=\"DONE\""
>
> When doing an org-mobile- push, I end up getting the following
> message:
>
> org-mobile-write-agenda-for-mobile: Invalid use of `\' in replacement
> text

Thanks for reporting this, should be fixed now.

Best,

-- 
 Bastien

[O] bug#10125: RFE: require and load-path-shadowing

[Bastien]

Stefan Monnier  writes:

> It's just an experiment (AFAIK).

Okay.

>>> "Check whether a required feature has been shadowed by changing
>>> `load-path' after it has been loaded and reload that feature from
>>> current load-path in this case."
>> I don't understand why we need this.
>
> For the case where Org is installed via package.el rather than by
> manually downloading and following some installation instructions.

In that case, isn't it enough to call (package-initialize) before
any Org configuration?

-- 
 Bastien

Re: [O] habits don't get re-scheduled

[Bastien]

Hi Karl,

Karl Voit  writes:

> I bisected this issue. It resulted in:

I should have fixed this now, please let me know!

Thanks a lot,

-- 
 Bastien

[O] bug#10125: RFE: require and load-path-shadowing

[Stefan Monnier]

 Yes, this subroutine is never directly called from C, so placing an
 advice should work just fine.
> I thought coding conventions prevented advising primitives?

Nothing prevents advising primitive functions (advising special forms
is another matter altogether).  But primitive functions can be called
from C directly (rather than via looking up the symbols' function cell)
in which case the advice will be ignored.

> I does not look clean to advise `require' here, just for Org.

It's just an experiment (AFAIK).

>> "Check whether a required feature has been shadowed by changing
>> `load-path' after it has been loaded and reload that feature from
>> current load-path in this case."
> I don't understand why we need this.

For the case where Org is installed via package.el rather than by
manually downloading and following some installation instructions.

> For package manager, a slightly more general version of the above (not
> conditionalized on the feature starting with "org" or "ob") could be
> used around the package compilation.  I haven't yet tried this, though.

Maybe the better way to do it is for package.el to compare the set of
files of the new package, with the set of currently loaded `features'
and unload the intersection.


Stefan

Re: [O] About `org-insert-heading' in Org's manual

[Bastien]

Hi Xue,

Xue Fuqiao  writes:

> Why do you think that?  I think that both import and export are
> important. Unless the file format is binary or closed (hard to analyse),
> importing is a good feature.

Yes, I strongly agree this is a very important feature, I'm just
saying this should not be developed as a feature of Org, but a more
general feature.

Best,

-- 
 Bastien

Re: [O] Error escaping '<' and '>' in HTML export

[Bastien]

Daniel Dehennin  writes:

> I tried to export as HTML some script I made and found that the exporter
> do not handle correctly URL in the form '' like in
> the GPL licence notice when followed by a line containing '>'

Fixed, thanks.

The problem was part of htmlize.el.

If you cannot get latest Org from git master, use this workaround:

  (setq htmlize-generate-hyperlinks nil)

Thanks,

-- 
 Bastien

[O] bug#10125: RFE: require and load-path-shadowing

[Eli Zaretskii]

> From: Stefan Monnier 
> Cc: Achim Gratz ,  10...@debbugs.gnu.org
> Date: Sat, 12 Jan 2013 08:28:29 -0500
> 
> > IOW, do you expect the byte-compile instances to be different in any
> > way from a fresh Emacs session invoked from the shell as "emacs -Q"?
> 
> Yes, because the current Emacs may be a different executable than the
> one the shell would run in response to "emacs -Q".

And if we make sure the same executable is run (easy on Windows)?  Are
there any other differences?

Re: [O] About `org-insert-heading' in Org's manual

[Xue Fuqiao]

On Sat, 12 Jan 2013 14:22:43 +0100
Bastien  wrote:

> See also http://permalink.gmane.org/gmane.emacs.orgmode/63815
Sorry for not noticing this thread.

> > 4. Audio and video insertion in Org;
> 
> Already possible.
I found it just now, thanks for your information.

> > 5. Alarm support (I'm strongly addicted to alarm);
> 
> Did you read the manual?
I'm an Org novice, and I'm still learning.

> > 6. Convert doc/pdf/xls... to Org files.
> 
> Not an Org task.
Why do you think that?  I think that both import and export are important. 
Unless the file format is binary or closed (hard to analyse), importing is a 
good feature.

Thanks.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: [O] In HTML export =code= appears too large compared to regular text

[Bastien]

Hi John,

John Corless  writes:

> I am interested in changing the appearance of =code= (or ~verbatim~
> for that matter) in HTML export.  In exporting the previous sentence
> with default =C-c C-e b=, the words code and verbatim are much larger
> than neighboring text.  Worg pages look much nicer (see examples on 
> http://orgmode.org/worg/), as do Wiki pages generated on Github with
> Gollum (using org-mode as markup, see my simple example at https://
> github.com/jdcorless/research-tools-notes/wiki/Emacs).  I would like
> to get the same appearance in my regular HTML exports.

You need to customize the CSS for this.  You can try this:

(setq org-export-html-style
   "

   ")

-- 
 Bastien

Re: [O] habits don't get re-scheduled

[Karl Voit]

* Bastien  wrote:
> Hi Karl,

Hi!

> Karl Voit  writes:
>
>> Another strange issue that I recognized today though: my habits do
>> not work any more: Whenever I mark an habit as DONE, it does not get
>> re-scheduled as is was before your recent changes. A CLOSED
>> time-stamp is added instead.
>>
>> Is there something I overlooked in the list of changes that I have
>> to adopt or do I face a bug?
>
> I tried to reproduce the issue but couldn't ... perhaps I need
> more info from your config file?   If you can go and bisect, that'd
> be great.  Thanks!

I bisected this issue. It resulted in:

,
| 8f749c983493a010c4ae0437975c8cb63017c3f4 is the first bad commit
| commit 8f749c983493a010c4ae0437975c8cb63017c3f4
| Author: Bastien Guerry 
| Date:   Mon Jan 7 12:33:57 2013 +0100
|
| org-depend.el (org-depend-trigger-todo): Refresh effort text properties
|
| * org-depend.el (org-depend-trigger-todo): Refresh effort text
| properties.  Do not use `org-get-effort' for getting the
| effort property value.
`

I also have to add, that *Messages* shows following lines when I set
an habit to DONE when using a commit-ID that has the issue mentioned
above:

,
| TODO state changed to DONE
| TODO state changed to TODO
| org-depend-trigger-todo: Symbol's function definition is void: 
org-refresh-effort-properties
| Note stored
`

-- 
Karl Voit

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

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 compress their Org files, and that (load "org-loaddefs.el") will
fail if they do, and that's why they need this patch.

If the additional complexity is just for this, I'm not convinced by
the patch.  If it fixes something else, please let me know.

-- 
 Bastien

[O] bug#10125: RFE: require and load-path-shadowing

[Bastien]

Achim Gratz  writes:

> Achim Gratz writes:
>> Stefan Monnier writes:
>>> Yes, this subroutine is never directly called from C, so placing an
>>> advice should work just fine.

I thought coding conventions prevented advising primitives?
I does not look clean to advise `require' here, just for Org.

>   "Check whether a required feature has been shadowed by changing
> `load-path' after it has been loaded and reload that feature from
> current load-path in this case."

I don't understand why we need this.  

This is at best a workaround to fix dirty installations.

I updated Org's installation process yesterday:

  http://orgmode.org/org.html#Installation

I made it clear that the user, if she wants to install Org on top of
the pre-bundled version, must choose between on of the three methods.
For each method, I explain how to set up the load-path (if needed) and
org.el will load the correct org-loaddefs.el, resetting autoloads
correctly.

In org.el, no Org package is required before org-loaddefs.el is loaded.

> This takes care of a situation when Org is activated after some parts of
> it have already been loaded (maybe via autoload) and the load-path has
> been changed inbetween.

I don't see why this should happen.  Setting the correct load-paths is
the first thing user should do in their .emacs.el.

-- 
 Bastien

[O] bug#10125: RFE: require and load-path-shadowing

[Stefan Monnier]

> IOW, do you expect the byte-compile instances to be different in any
> way from a fresh Emacs session invoked from the shell as "emacs -Q"?

Yes, because the current Emacs may be a different executable than the
one the shell would run in response to "emacs -Q".


Stefan

Re: [O] About `org-insert-heading' in Org's manual

[Bastien]

Xue Fuqiao  writes:

> 1. Build an architecture that supports sharing org files and online real-time 
> collaboration;

See Worg.  That's what we com'up best.

See also http://permalink.gmane.org/gmane.emacs.orgmode/63815

> 2. MobileOrg for Freerunner/Mer/Firefox OS/Bada/Windows Phone...

Please go ahead.

> 3. Web applications that use org-mode files as a back end for storing data;

Good idea.  Github does it, and perhaps others.
Also see the link above.

> 4. Audio and video insertion in Org;

Already possible.

> 5. Alarm support (I'm strongly addicted to alarm);

Did you read the manual?

> 6. Convert doc/pdf/xls... to Org files.

Not an Org task.

Best,

-- 
 Bastien

[O] In HTML export =code= appears too large compared to regular text

[John Corless]

Hello,

I am interested in changing the appearance of =code= (or ~verbatim~ for
that matter) in HTML export.  In exporting the previous sentence with
default =C-c C-e b=, the words code and verbatim are much larger than
neighboring text.  Worg pages look much nicer (see examples on
http://orgmode.org/worg/), as do Wiki pages generated on Github with Gollum
(using org-mode as markup, see my simple example at
https://github.com/jdcorless/research-tools-notes/wiki/Emacs).  I would
like to get the same appearance in my regular HTML exports.

GNU Emacs 24.1.1
Org-mode version 7.8.11

I have tried searching org-mode manual, searching email archive, and
stackoverflow but have not been successful with this rather specific issue.

Thank you,

John D. Corless
jdcorl...@gmail.com

[O] Custom Agenda with Tag search for multiple items ( \\ Between search terms) fails push

[Jeff Myer]

I have a custom agenda item in my .emacs file that is for a Tags search for
multiple items as follows (not the whole thing just the bit that is giving
me trouble):

"E" "Items Tagged for the Engineering Staff" tags
"{Allen\\|Dave\\|JimD\\|Heming\\|Paul\\|EdM}-TODO=\"DONE\""

When doing an org-mobile- push, I end up getting the following message:

org-mobile-write-agenda-for-mobile: Invalid use of `\' in replacement text

The problem appears to be the double back slashes confirmed by  replacing
\\ with \ and not having the error on push. The problem is that the agenda
item does not work correctly without the double backslashes.

I am not an expert with Emacs/Org-mode customization so if I have
overlooked something obvious, please feel free to point me in the right
direction to learn more about how to correct on my own.

Was running GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10)
Updated to 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) of
2013-01-11

Was Using  Org-mode version 6.33x updated to Org-mode version 7.9.3a with
no change.

[O] Error escaping '<' and '>' in HTML export

[Daniel Dehennin]

Hello,

I tried to export as HTML some script I made and found that the exporter
do not handle correctly URL in the form '' like in
the GPL licence notice when followed by a line containing '>'

For example:

#+begin_src sh
  #!/bin/sh
  
  # This program is free software: you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
  # the Free Software Foundation, either version 3 of the License, or
  # (at your option) any later version.
  #
  # This program is distributed in the hope that it will be useful,
  # but WITHOUT ANY WARRANTY; without even the implied warranty of
  # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  # GNU General Public License for more details.
  #
  # You should have received a copy of the GNU General Public License
  # along with this program.  If not, see .
  
  # Report bug to Hello Bug Tracking system 

  echo "Hello World"
#+end_src

produce the following:

#+begin_src html
# along with 
this program.  If not, see http://www.gnu.org/licenses/>.

# Report bug to Hello Bug Tracking system 
hello-...@example.net">;.http://www.gnu.org/licenses/>.

# Report bug to Hello Bug Tracking system hello-...@example.net">

http://www.gnu.org/licenses/>.

# Report bug to Hello Bug Tracking system hello-...@example.net"># 
http://www.gnu.org/licenses/>.

# Report bug to Hello Bug Tracking system hello-...@example.net">Report bug to 
Hello Bug Tracking system hello-...@example.net>
#+end_src

Regards.

-- 
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x7A6FE2DF


pgp9zmauoD8dX.pgp
Description: PGP signature

Re: [O] About `org-insert-heading' in Org's manual

[Xue Fuqiao]

On Sat, 12 Jan 2013 09:52:36 +0100
Bastien  wrote:

> If you want to contribute to Org, please try to make constructive and
> useful suggestions first: that way you'll get write access and be able
> to fix those tiny things that don't matter that much.

Thanks for your reply.  I have a few suggestions (maybe not constructive):
1. Build an architecture that supports sharing org files and online real-time 
collaboration;
2. MobileOrg for Freerunner/Mer/Firefox OS/Bada/Windows Phone...
3. Web applications that use org-mode files as a back end for storing data;
4. Audio and video insertion in Org;
5. Alarm support (I'm strongly addicted to alarm);
6. Convert doc/pdf/xls... to Org files.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

[O] bug#10125: RFE: require and load-path-shadowing

[Eli Zaretskii]

> From: Achim Gratz 
> Date: Sat, 12 Jan 2013 11:20:58 +0100
> 
> Eli Zaretskii writes:
> >> Could be: depends on the precise semantics of spawn, which I don't know.
> >
> > I'm barely following this thread, so please tell what semantics do you
> > need, and I will then try figuring out whether spawn does what you
> > need.
> 
> The idea IIUC is to fork/spawn Emacs after it has initialized to be able
> to use a "pristine" instance to spawn off again for byte compilation.
> 
> emacs-pristine +--- emacs-user
>|
>+--- emacs-bytecompile-1
>|
>+--- emacs-bytecompile-2
>|
>+--- emacs-bytecompile-3

How is this different from invoking emacs-bytecompile-N instances in
parallel to invoking emacs-pristine?  IOW, do you expect the
byte-compile instances to be different in any way from a fresh Emacs
session invoked from the shell as "emacs -Q"?

Re: [O] [new exporter] adhere org-export-date-timestamp-format?

[Nicolas Goaziou]

Bastien  writes:

> I agree they are general and should be move out of org-export.el.
>
> Note that one of my plan for 8.[01] is to put org.el on diet so that
> it loads more quickly and for more basic stuff.  So maybe there will
> be org-plan.el at some point for org-schedule, org-deadline and 
> anything related to planning.  Ideally, Org would *just* be outline
> reloaded (with orgtble and all editing facilities), while other
> features would have their own library.  So maybe those functions
> will end up outside of org.el one day... but I'd say it's okay
> to have them in org.el for now.

The attached patch moves them into org.el, with an org-timestamp-
prefix.

Though, I think I have to withdraw my proposal about using #+DATE: value
as a time format string. Indeed, date value, along with any document
property, is parsed, which defeats the purpose of using it as a format
string.

We can still implement a convenient macro to handle timestamps in date
keyword.

What do you think?


Regards,

-- 
Nicolas Goaziou
>From 564dbaa3f7a694c2b46074e7ccc529a310ad5b7d Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Thu, 10 Jan 2013 21:42:21 +0100
Subject: [PATCH] Move functions operating on timestamp objects into org.el

* contrib/lisp/org-export.el (org-export-timestamp-has-time-p,
  org-export-format-timestamp, org-export-split-timestamp-range,
  org-export-translate-timestamp): Removed functions.
* lisp/org.el (org-timestamp-has-time-p, org-timestamp-format,
  org-timestamp-split-range, org-timestamp-translate): New functions.
* contrib/lisp/org-e-ascii.el (org-e-ascii-timestamp): Apply move.
* contrib/lisp/org-e-groff.el (org-e-groff-timestamp): Apply move.
* contrib/lisp/org-e-html.el (org-e-html-timestamp): Apply move.
* contrib/lisp/org-e-latex.el (org-e-latex-timestamp): Apply move.
* contrib/lisp/org-e-odt.el (org-e-odt--format-timestamp,
  org-e-odt-timestamp): Apply move.
* contrib/lisp/org-e-texinfo.el (org-e-texinfo-timestamp): Apply move.
* testing/lisp/test-org-export.el: Remove tests.
* testing/lisp/test-org.el: Add tests.
---
 contrib/lisp/org-e-ascii.el |   2 +-
 contrib/lisp/org-e-groff.el |   2 +-
 contrib/lisp/org-e-html.el  |   2 +-
 contrib/lisp/org-e-latex.el |   2 +-
 contrib/lisp/org-e-odt.el   |  10 ++--
 contrib/lisp/org-e-texinfo.el   |   2 +-
 contrib/lisp/org-export.el  |  90 
 lisp/org.el |  88 
 testing/lisp/test-org-export.el | 126 
 testing/lisp/test-org.el| 126 
 10 files changed, 224 insertions(+), 226 deletions(-)

diff --git a/contrib/lisp/org-e-ascii.el b/contrib/lisp/org-e-ascii.el
index 4499de5..7bfc4c2 100644
--- a/contrib/lisp/org-e-ascii.el
+++ b/contrib/lisp/org-e-ascii.el
@@ -1706,7 +1706,7 @@ a communication channel."
 (defun org-e-ascii-timestamp (timestamp contents info)
   "Transcode a TIMESTAMP object from Org to ASCII.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (org-e-ascii-plain-text (org-export-translate-timestamp timestamp) info))
+  (org-e-ascii-plain-text (org-timestamp-translate timestamp) info))
 
 
  Underline
diff --git a/contrib/lisp/org-e-groff.el b/contrib/lisp/org-e-groff.el
index e91de34..c7fbeac 100644
--- a/contrib/lisp/org-e-groff.el
+++ b/contrib/lisp/org-e-groff.el
@@ -1852,7 +1852,7 @@ information."
 CONTENTS is nil.  INFO is a plist holding contextual
 information."
   (let ((value (org-e-groff-plain-text
-		(org-export-translate-timestamp timestamp) info)))
+		(org-timestamp-translate timestamp) info)))
 (case (org-element-property :type timestamp)
   ((active active-range)
(format org-e-groff-active-timestamp-format value))
diff --git a/contrib/lisp/org-e-html.el b/contrib/lisp/org-e-html.el
index 7a37d29..ab46e2a 100644
--- a/contrib/lisp/org-e-html.el
+++ b/contrib/lisp/org-e-html.el
@@ -2684,7 +2684,7 @@ information."
 CONTENTS is nil.  INFO is a plist holding contextual
 information."
   (let ((value (org-e-html-plain-text
-		(org-export-translate-timestamp timestamp) info)))
+		(org-timestamp-translate timestamp) info)))
 (format "%s"
 	(replace-regexp-in-string "--" "–" value
 
diff --git a/contrib/lisp/org-e-latex.el b/contrib/lisp/org-e-latex.el
index 7d165d3..6ac8e86 100644
--- a/contrib/lisp/org-e-latex.el
+++ b/contrib/lisp/org-e-latex.el
@@ -2597,7 +2597,7 @@ information."
 CONTENTS is nil.  INFO is a plist holding contextual
 information."
   (let ((value (org-e-latex-plain-text
-		(org-export-translate-timestamp timestamp) info)))
+		(org-timestamp-translate timestamp) info)))
 (case (org-element-property :type timestamp)
   ((active active-range) (format org-e-latex-active-timestamp-format value))
   ((inactive inactive-range)
diff --git a/contrib/lisp/org-e-odt.el b/contrib/lisp/org-e-odt.el
index ded4b02..7ba2d9d 100644
--- a/contrib/lisp/org-e-odt.el
+++ b/contr

[O] bug#10125: RFE: require and load-path-shadowing

[Achim Gratz]

Eli Zaretskii writes:
>> Could be: depends on the precise semantics of spawn, which I don't know.
>
> I'm barely following this thread, so please tell what semantics do you
> need, and I will then try figuring out whether spawn does what you
> need.

The idea IIUC is to fork/spawn Emacs after it has initialized to be able
to use a "pristine" instance to spawn off again for byte compilation.

emacs-pristine +--- emacs-user
   |
   +--- emacs-bytecompile-1
   |
   +--- emacs-bytecompile-2
   |
   +--- emacs-bytecompile-3

Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

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]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] [PATCH] New LaTeX exporter, switch for hypersetup

[Nicolas Goaziou]

t...@tsdye.com (Thomas S. Dye) writes:

> Thanks for the good explanation and suggestions.  A (hopefully) better
> patch is attached.

Thank you. It looked good, I applied it. I also applied it to `e-beamer'
back-end for completeness.


Regards,

-- 
Nicolas Goaziou

[O] bug#10125: RFE: require and load-path-shadowing

[Achim Gratz]

Achim Gratz writes:
> Stefan Monnier writes:
>> Yes, this subroutine is never directly called from C, so placing an
>> advice should work just fine.
>
> OK, I'll give it a try.

Here's what I've come up with:

--8<---cut here---start->8---
;; some parts of Org might already have been used from a different
;; place, try to reload these parts from the current load-path
(defadvice require (before org-require-reload-when-shadowed
   (feature &optional filename noerror)
   activate compile preactivate)
  "Check whether a required feature has been shadowed by changing
`load-path' after it has been loaded and reload that feature from
current load-path in this case."
  (when (featurep feature)
(let ((feature-name (or filename (symbol-name feature
  (when (string-match "^\\(org\\|ob\\)[.-]" feature-name)
(let ((feature-lib  (file-name-directory (or (locate-library 
feature-name) "")))
  (feature-dir  (file-name-directory (feature-file feature
  ;(message "require-reload-when shadowed %s\n\t%s\n\t%s" feature-name 
feature-lib feature-dir)
  (when (not (string= feature-lib feature-dir))
(message "Reloading %s" feature-name)
(unload-feature feature t)))
(require 'org-macs)
(require 'org-compat)
(require 'org-entities)
(require 'org-faces)
(require 'org-list)
(require 'org-pcomplete)
(require 'org-src)
(require 'org-footnote)
;; babel
(require 'ob)
(eval-and-compile (ad-unadvise 'require))
--8<---cut here---end--->8---

This takes care of a situation when Org is activated after some parts of
it have already been loaded (maybe via autoload) and the load-path has
been changed inbetween.  This uses unload-feature although it would
probably work to just (setq features (delq feature features)).

For package manager, a slightly more general version of the above (not
conditionalized on the feature starting with "org" or "ob") could be
used around the package compilation.  I haven't yet tried this, though.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Achim Gratz]

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 difficult
> to do here either).

The attached patch series will implement a workaround that unloads any
features that have already been loaded with a different load-path so
that the correct files from the current load-path will prevail.  This
should solve the reported problems with the init file using parts of Org
before the load-path is set up.  The implementation uses unload-feature,
so customizations loaded previously (instead of at the very end as they
should) might vanish.  Please report if any init systems do this.

Package manager will still fail in certain situations when Org is
installed via ELPA in an Emacs session that has already used another
version of Org.  This needs to be fixed in package manager, there's no
workaround to do this from Org's side.

>From c6b5e0daafb2f6e43ba936a85969b134037ff912 Mon Sep 17 00:00:00 2001
From: Achim Gratz 
Date: Sat, 12 Jan 2013 08:55:07 +0100
Subject: [PATCH 1/3] Revert "org.el ("org-loaddefs.el"): use `load', not
 `org-load-noerror-mustsuffix'"

This reverts commit db7ece9fa2e27944d9482961af9bfd9d08bb3b51.
---
 lisp/org.el | 47 ---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 1c2ee9a..e979b35 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -78,11 +78,12 @@ (defvar org-table-formula-constants-local nil
 (require 'find-func)
 (require 'format-spec)
 
-(load "org-loaddefs.el" t t t)
-
 (require 'org-macs)
 (require 'org-compat)
 
+(let ((load-suffixes (list ".el")))
+  (org-load-noerror-mustsuffix "org-loaddefs"))
+
 ;; `org-outline-regexp' ought to be a defconst but is let-binding in
 ;; some places -- e.g. see the macro org-with-limited-levels.
 ;;
@@ -16901,27 +16902,6 @@ (defun org-date-from-calendar ()
   (org-insert-time-stamp
(encode-time 0 0 0 (nth 1 cal-date) (car cal-date) (nth 2 cal-date))
 
-(defcustom org-effort-durations
-  `(("h" . 60)
-("d" . ,(* 60 8))
-("w" . ,(* 60 8 5))
-("m" . ,(* 60 8 5 4))
-("y" . ,(* 60 8 5 40)))
-  "Conversion factor to minutes for an effort modifier.
-
-Each entry has the form (MODIFIER . MINUTES).
-
-In an effort string, a number followed by MODIFIER is multiplied
-by the specified number of MINUTES to obtain an effort in
-minutes.
-
-For example, if the value of this variable is ((\"hours\" . 60)), then an
-effort string \"2hours\" is equivalent to 120 minutes."
-  :group 'org-agenda
-  :version "24.1"
-  :type '(alist :key-type (string :tag "Modifier")
-		:value-type (number :tag "Minutes")))
-
 (defun org-minutes-to-clocksum-string (m)
   "Format number of minutes as a clocksum string.
 The format is determined by `org-time-clocksum-format',
@@ -17031,6 +17011,27 @@ (defun org-hh:mm-string-to-minutes (s)
 (string-to-number (match-string 1 s)))
(t 0)))
 
+(defcustom org-effort-durations
+  `(("h" . 60)
+("d" . ,(* 60 8))
+("w" . ,(* 60 8 5))
+("m" . ,(* 60 8 5 4))
+("y" . ,(* 60 8 5 40)))
+  "Conversion factor to minutes for an effort modifier.
+
+Each entry has the form (MODIFIER . MINUTES).
+
+In an effort string, a number followed by MODIFIER is multiplied
+by the specified number of MINUTES to obtain an effort in
+minutes.
+
+For example, if the value of this variable is ((\"hours\" . 60)), then an
+effort string \"2hours\" is equivalent to 120 minutes."
+  :group 'org-agenda
+  :version "24.1"
+  :type '(alist :key-type (string :tag "Modifier")
+		:value-type (number :tag "Minutes")))
+
 (defcustom org-image-actual-width t
   "Should we use the actual width of images when inlining them?
 
-- 
1.8.1

>From 6e158e45fad2c56c37e3cacee772102aec89dbd3 Mon Sep 17 00:00:00 2001
From: Achim Gratz 
Date: Sat, 12 Jan 2013 08:55:51 +0100
Subject: [PATCH 2/3] Revert "`org-load-noerror-mustsuffix' requires an
 autoload"

This reverts commit f94d81a17e2c947a474e0f3b274c46afc3aa99a9.
---
 lisp/org-macs.el | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 974a366..e5d6100 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -426,7 +426,6 @@ (defun org-make-parameter-alist (flat)
 (cons (list (car flat) (cadr flat))
 	  (org-make-parameter-alist (cddr flat)
 
-;;;###autoload
 (defmacro org-load-noerror-mustsuffix (file)
   "Load FILE with optional arguments NOERROR and MUSTSUFFIX.  Drop the MUSTSUFFIX argument for XEmacs, which doesn't recognize it."
   (if (featurep 'xemacs)
-- 
1.8.1

>From dd67ebfa2366ba5a275886c7c68f96643c59280b Mon Sep 17 00:00:00 2001
From: Achim Gratz 
Date: Sat, 12 Jan 2013 11:50:27 +0100
Subject: [PATCH 3/3] org.el: advice around require to defuse mixed-install
 scenario

* lisp/org.el (require-reloads-when-shado

Re: [O] org agenda extensions

[Thomas Alexander Gerds]

Hi Bastien

ok. will investigate. thanks for now.

Best Thomas


Bastien  writes:

> Hi Thomas,
>
> Thomas Alexander Gerds  writes:
>
>> I feel that your proposal to first create the agenda using the standard
>> `org-agenda-format-item' function and then to replace all lines again,
>> by calling a suitable function added to `org-agenda-finalize-hook' is
>> not very efficient.
>
> Imagine you have a 1 items agenda file, and you produce a 100
> items agenda view.  Your method would slow down checking 1 items
> to display properties for 100 items, while my method would slow down
> the display of the 100 already available items.  So its about 100x
> faster.
>
> Please check both methods and let us know what performance you
> observe.
>
>> but, since you agree that when `org-agenda-property-list' is nil no harm
>> is done, and if your objection mostly is about the name, then how about
>>
>> `org-agenda-overriding-format-item-function'
>
> My objection is about the method.
>
>> ps: I would volunteer to assist users who copy stuff from the web and of
>> course also deliver documentation and examples for
>> `org-agenda-property-list'.
>
> Thanks for this -- but as I said, there are performance issues and
> design issues (not introducing formatting properties within
> org-scan-tags.)  
>
> Best,
--
Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics
University of Copenhagen, Øster Farimagsgade 5, 1014 Copenhagen, Denmark
Office: CSS-15.2.07 (Gamle Kommunehospital)
tel: 35327914 (sec: 35327901) 

Re: [O] org agenda extensions

[Bastien]

Hi Thomas,

Thomas Alexander Gerds  writes:

> I feel that your proposal to first create the agenda using the standard
> `org-agenda-format-item' function and then to replace all lines again,
> by calling a suitable function added to `org-agenda-finalize-hook' is
> not very efficient.

Imagine you have a 1 items agenda file, and you produce a 100
items agenda view.  Your method would slow down checking 1 items
to display properties for 100 items, while my method would slow down
the display of the 100 already available items.  So its about 100x
faster.

Please check both methods and let us know what performance you
observe.

> but, since you agree that when `org-agenda-property-list' is nil no harm
> is done, and if your objection mostly is about the name, then how about
>
> `org-agenda-overriding-format-item-function'

My objection is about the method.

> ps: I would volunteer to assist users who copy stuff from the web and of
> course also deliver documentation and examples for
> `org-agenda-property-list'.

Thanks for this -- but as I said, there are performance issues and
design issues (not introducing formatting properties within
org-scan-tags.)  

Best,

-- 
 Bastien

Re: [O] org agenda extensions

[Thomas Alexander Gerds]

Hi Bastien

I feel that your proposal to first create the agenda using the standard
`org-agenda-format-item' function and then to replace all lines again,
by calling a suitable function added to `org-agenda-finalize-hook' is
not very efficient.

but, since you agree that when `org-agenda-property-list' is nil no harm
is done, and if your objection mostly is about the name, then how about

`org-agenda-overriding-format-item-function'

Best,
Thomas

ps: I would volunteer to assist users who copy stuff from the web and of
course also deliver documentation and examples for
`org-agenda-property-list'.



Bastien  writes:

> Hi Thomas,
>
> Thomas Alexander Gerds  writes:
>
>> thanks for looking into this! I understand your general point of
>> view. however, the proposed changes would only slow down agenda creating
>> if org-agenda-property-list is set, right?
>
> Right.
>
>> also, it certainly requires some insights to write
>> org-agenda-overriding-agenda-format which could display non-special
>
> (`org-agenda-overriding-agenda-format' is a confusing name IMHO.)
>
>> properties. hence only a user who knows what she/he is doing would run
>> into this problem.
>
> Many users just copy stuff from the web, and some are not really
> knowing what they do.
>
>> anyway, could you propose a different approach to get this
>> extension?
>
> You can write a function for `org-agenda-finalize-hook' which would go
> through the agenda lines, get the properties and display them.
>
> That's a far better approach.
>
>> ps: one limitation of org-agenda-columns seems to be that columns
>> cannot be activated in two different agenda buffers simulaneously.
>
> Yes, we can work on this.
>
> Best,
--
Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics
University of Copenhagen, Øster Farimagsgade 5, 1014 Copenhagen, Denmark
Office: CSS-15.2.07 (Gamle Kommunehospital)
tel: 35327914 (sec: 35327901) 

Re: [O] About `org-insert-heading' in Org's manual

[Bastien]

Hi Xue,

Xue Fuqiao  writes:

> In (info "(org) Plain lists"):
> `M-' (`org-insert-heading')
>  Insert new item at current level.  With a prefix argument, force a
>  new heading (*note Structure editing::).  If this command is used
>  in the middle of an item, that item is _split_ in two, and the
>  second part becomes the new item(7).  If this command is executed
>  _before item's body_, the new item is created _before_ the current
>  one.
>
> Why is `before item's body' emphasized?  As far as I'm concerned, only
> `before' should be emphasized.

I don't mind.  

> BTW, why is the node name `Plain lists'?  In Emacs manuals, all the
> node name are made of capitalized words, for example:
> (info "(emacs) Saving Emacs Sessions")
> (info "(elisp) Syntax Tables")
> (info "(widget) Widget Wishlist")
> ...

In Org's manual, not all the node names are made of capitalized words.

If you want to contribute to Org, please try to make constructive and
useful suggestions first: that way you'll get write access and be able
to fix those tiny things that don't matter that much.

Bye,

-- 
 Bastien

Re: [O] org agenda extensions

[Bastien]

Hi Thomas,

Thomas Alexander Gerds  writes:

> thanks for looking into this! I understand your general point of
> view. however, the proposed changes would only slow down agenda creating
> if org-agenda-property-list is set, right?

Right.

> also, it certainly requires some insights to write
> org-agenda-overriding-agenda-format which could display non-special

(`org-agenda-overriding-agenda-format' is a confusing name IMHO.)

> properties. hence only a user who knows what she/he is doing would run
> into this problem.

Many users just copy stuff from the web, and some are not really
knowing what they do.

> anyway, could you propose a different approach to get this
> extension?

You can write a function for `org-agenda-finalize-hook' which would go
through the agenda lines, get the properties and display them.

That's a far better approach.

> ps: one limitation of org-agenda-columns seems to be that columns
> cannot be activated in two different agenda buffers simulaneously.

Yes, we can work on this.

Best,

-- 
 Bastien

Re: [O] Fixes for org-capture-templates-contexts

[Bastien]

Hi Darlan,

Darlan Cavalcante Moreira  writes:

> By a great coincidence I just discovered org-capture-templates-contexts
> yesterday but could not make it work yet (didn't have much time to
> investigate it). 

Please try to customize `org-capture-templates-contexts' using the
customize interface.  The docstring was giving wrong direction (it 
is fixed in latest git though.)

> Is it possible to have capture templates that do not
> appear in any buffer but can be called from lisp? 

(setq org-capture-templates-contexts 
  '(("c" ((not-in-mode . "emacs-lisp-mode")

> ps: this rule affecting all sub-templates will also be very userful.

+1!

HTH,

-- 
 Bastien

Re: [O] Fixes for org-capture-templates-contexts

[Bastien]

Hi Paul,

Paul Sexton  writes:

> org-capture-templates-contexts currently appears not to work. 

Actually it works, but the docstring where misleading, I fixed them.

> - new context specifiers in-buffer and not-in-buffer
> - in-mode and not-in-mode expect a symbol, not a regexp.
> - if a rule specifies a template that has 'sub-templates', those sub-templates
>   will also be affected by the rule. For example if you have templates 't',
>   'ta', 'tb' and 'tc', you can specify a rule for 't' which will affect
>   all of them.

If you can send a patch against master for this, I'd be happy to apply
it!  Thanks again for pointing to these problems,

-- 
 Bastien

Re: [O] [BUG] `org-load-noerror-mustsuffix´ is not defined, introduced by 5484a33b

[Bastien]

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 like loaddefs.el.
>
> Why should I?  

Please do send a link to a loaddefs.el.gz anywhere on the web or
anywhere in an Emacs package or provide a way to install Emacs which
generates loaddefs.el.gz.

> It is not at all illegal to do this, so we shouldn't be putting out code
> that actively prevents this option.  That Emacs currently doesn't do
> this has different reasons and looking at the code Emacs uses makes it
> abundantly clear that they've gone to great lengths to enable this for
> all files.  Currently it usually is faster to read non-compressed files
> from disk if they aren't larger than a single allocation unit of the
> underlying file system (which is why the files Emacs uses most often,
> that is .elc files and autoloads are kept uncompressed), but there are
> situations were there is a clear advantage of using compression and
> there are also situations where compressing _all_ files is the only
> thing left to do.

If you want to fix Emacs with respect to allowing loaddefs.el and
org-loaddefs.el compression, please do.

-- 
 Bastien

[O] bug#10125: RFE: require and load-path-shadowing

[Eli Zaretskii]

> From: Stefan Monnier 
> Date: Fri, 11 Jan 2013 17:52:33 -0500
> Cc: 10...@debbugs.gnu.org
> 
>  I guess we could fork Emacs early on and keep this second process
>  around as a "process from which to generate new clean slates".
> >>> I've been thinking about something like this for a while… if it worked
> >>> at least as well as starting a new Emacs instance on all platforms, I'd
> >>> favor this approach.
> >> IIUC "fork" is not really an option for w32.
> > For the intended application spawn should work as well?
> 
> Could be: depends on the precise semantics of spawn, which I don't know.

I'm barely following this thread, so please tell what semantics do you
need, and I will then try figuring out whether spawn does what you
need.