Re: [O] Bug: Tag inheritance broken in agenda/timeline buffers [7.9.3a (release_7.9.3a-803-gf8f548 @ /home/horn/Repos/el/org-mode/lisp/)]

[Tassilo Horn]

Tassilo Horn  writes:

> I have (all default values)
>
>   org-use-tag-inheritance t
>   org-agenda-use-tag-inheritance '(todo search timeline agenda)
>   org-agenda-show-inherited-tags t
>
> but there are no inherited tags shown in the agenda or an org-buffer's
> timeline.
>
> When I press `T' on a agenda entry, the inherited tags are properly
> messaged in the echo area, though.  I'm sure it used to work, but I'm
> not sure when it stopped working.  When I find some time, I can try
> bisecting.

I've done the bisecting:

7684fbd6a227f0ad182661fd7eb17a9e13dc4695 is the first bad commit
commit 7684fbd6a227f0ad182661fd7eb17a9e13dc4695
Author: Nicolas Goaziou 
Date:   Tue Jan 8 10:34:40 2013 +0100

Ignore `auto-fill-inhibit-regexp'

* lisp/org.el (org-setup-filling): Ignore `auto-fill-inhibit-regexp'.
  The idea behind this is that `org-adaptive-fill-function' already
  determines which lines should be filled.

:04 04 a3246c36c59e412bd43df6afa0088d2499268265
7e69342d3b487a61a2cb6bba62b3262896fcdaab M  lisp

Now don't ask me how that change affects tag inheritance?!

Bye,
Tassilo

Re: [O] Bug: Tag inheritance broken in agenda/timeline buffers [7.9.3a (release_7.9.3a-803-gf8f548 @ /home/horn/Repos/el/org-mode/lisp/)]

[Tassilo Horn]

Tassilo Horn  writes:

>> When I press `T' on a agenda entry, the inherited tags are properly
>> messaged in the echo area, though.  I'm sure it used to work, but I'm
>> not sure when it stopped working.  When I find some time, I can try
>> bisecting.
>
> I've done the bisecting:
>
> 7684fbd6a227f0ad182661fd7eb17a9e13dc4695 is the first bad commit
> commit 7684fbd6a227f0ad182661fd7eb17a9e13dc4695
> Author: Nicolas Goaziou 
> Date:   Tue Jan 8 10:34:40 2013 +0100
>
> Ignore `auto-fill-inhibit-regexp'

Sorry for the noise, but I must have done something wrong during
bisect.  The previous commit is also "bad", so Nicolas isn't the one to
blame here.  I'll bisect again...

Bye,
Tassilo

Re: [O] Bug: Tag inheritance broken in agenda/timeline buffers [7.9.3a (release_7.9.3a-803-gf8f548 @ /home/horn/Repos/el/org-mode/lisp/)]

[Tassilo Horn]

Tassilo Horn  writes:

>> I've done the bisecting:
>>
>> 7684fbd6a227f0ad182661fd7eb17a9e13dc4695 is the first bad commit
>> commit 7684fbd6a227f0ad182661fd7eb17a9e13dc4695
>> Author: Nicolas Goaziou 
>> Date:   Tue Jan 8 10:34:40 2013 +0100
>>
>> Ignore `auto-fill-inhibit-regexp'
>
> Sorry for the noise, but I must have done something wrong during
> bisect.  The previous commit is also "bad", so Nicolas isn't the one
> to blame here.  I'll bisect again...

Ok, here's the new bisecting result, and that seems reasonable:

c8bfd50223d1a75d12d7f74571c24951592c56ec is the first bad commit
commit c8bfd50223d1a75d12d7f74571c24951592c56ec
Author: Bastien Guerry 
Date:   Mon Jan 7 16:12:52 2013 +0100

org-agenda.el: New option `org-agenda-use-tag-inheritance'

* org-agenda.el (org-search-view, org-agenda-get-todos)
(org-agenda-get-timestamps, org-agenda-get-sexps)
(org-agenda-get-progress, org-agenda-get-deadlines)
(org-agenda-get-scheduled, org-agenda-get-blocks)
(org-agenda-change-all-lines): Get local tags only.
(org-agenda-use-tag-inheritance): New option.
(org-agenda-finalize): When `org-agenda-use-tag-inheritance'
is non-nil, possibly reset tags in the agenda buffer.
(org-agenda-check-type): Enhance docstring.

See the docstring of the new option for details.

:04 04 78b4635191f9aadf4fb1e4aaf4fce5c503e24ef6
cfc6f54ff9328ec0f338f2050b913ae7dfbb399b M  lisp

In the diff of that commit, I see a lot of changes like

- (setq tags (org-get-tags-at))
+ (setq tags (org-get-tags-at nil t))

i.e., it used to show all tags (local and inherited), and now it's
explicitly said to display only local tags.

I've validated the result: with c8bfd50223d1a75d12d7f74571c24951592c56ec
tag inheritance is broken, with its predecessor babba02 it does work
again.

Bye,
Tassilo

Re: [O] BBDB(3) or org-contacts

[Michael Strey]

On Wed, Jan 09, 2013 at 03:16:09PM +0100, Gour wrote:

[...]

> > I use this as Customer Relationship Management (CRM) system.
> 
> ...and would like to use it as CRM as well. Can you, please, share some
> more info about your setup (I'll probably use Gnus instead of Mutt)?

Here is my YASnippet template for the organisation

,
| #name : Contact Organisation
| #key : org
| #contributor : Michael Strey <[EMAIL PROTECTED]>
| # --
| ** ${1:organisation}
| :PROPERTIES:
| :KIND: org
| :ORG:  $1;${2:devision}
| 
:ADR;TYPE=work:${3:adr1};${4:adr2};${5:adr3};${6:city};${7:state};${8:zip_code};${9:country}
| :EMAIL:mailto:${10:company_email}
| :TEL;PREF=1;TYPE="voice,work":[[tel:${11:tel}]]
| :TEL;TYPE="fax,work":[[tel:${12:fax}]]
| :URL:  http://$13
| :LANG: $14
| :END:
| $0
| Added: [`(org-read-date nil nil "+0d")`]
`

and here that for a contact in the next sub-level

,
| #name : Contact Individual
| #key : contact
| #contributor : Michael Strey <[EMAIL PROTECTED]>
| # --
| *** ${1:surname}, ${2:name}
| :LOGBOOK:
| - Added: [`(org-read-date nil nil "+0d")`]
| :END:
| 
| :PROPERTIES:
| :KIND: individual
| :ORG:  ${3:organisation};${4:devision}
| :TITLE:${5:title}
| :FN:   $2 $1
| :N:$1;$2;;
| :NICKNAME: $19 $1
| 
:ADR;TYPE=work:${6:adr1};${7:adr2};${8:adr3};${9:city};${10:state};${11:zip_code};${12:country}
| :EMAIL:mailto:${13:company_email}
| :TEL;PREF=1;TYPE="voice,work":[[tel:${14:tel}]]
| :TEL;TYPE="voice,cell":[[tel:${15:mobile}]]
| :TEL;TYPE="fax,work":[[tel:${16:fax}]]
| :URL:  http://$17
| :LANG: $18
| :END:
| $0
`

For my private contacts I have a simpler template

,
| #name : Contact Individual (private)
| #key : privat
| #contributor : Michael Strey <[EMAIL PROTECTED]>
| # --
| *** ${1:surname}, ${2:name}
| :PROPERTIES:
| :KIND: individual
| :FN:   $2 $1
| :N:$1;$2;;
| :NICKNAME: ${3:salutation}
| 
:ADR;TYPE=home:;;${4:adr3};${5:Dresden};${6:Sachsen};${7:zip_code};${8:Deutschland}
| :EMAIL:mailto:${9:email}
| :TEL;PREF=1;TYPE="voice,home":[[tel:${10:tel}]]
| :TEL;TYPE="voice,cell":[[tel:${11:mobile}]]
| :LANG: ${12:de}
| :END:
| $0
| Added: [`(org-read-date nil nil "+0d")`]
`


The LOGBOOK drawer is used to store log notes with C-c C-z.  In the lead
phase, as long as I do not have a dedicated sales project with a contact
or organisation, I store all notes below the individual or organisation
respectively.

As soon as there is a real chance to sell something, I define a sales
project in a second file containing all of my sales projects.  Here
comes the YASnippet for such a project.

,
| #name : Sales Project
| #key : salesp
| #contributor : Michael Strey <[EMAIL PROTECTED]>
| # --
| *** PENDING ${1:customer} -- ${2:product} 
  :SP:
| :PROPERTIES:
| :Customer: $1
| :Vendor:   ${3:vendor}
| :Product:  $2
| :Quantity_short: ${4:quantity}
| :Quantity_long:  ${5:quantity_long}
| :Price:${6:price}
| :Rate: ${7:0.1}
| :Probability: ${8:0.5}
| :PlannedDeliveryDate:
| :Delivered: [ ]
| :Invoices: [ ]
| :Payed:[ ]
| :COLUMNS: %Customer %Product %Price %Quantity_short(Qty$_1$) 
%Probability(Prob.) %Value1(Value) %Quantity_long(Qty$_2$) %Value2(Potential)
| :END:
| Added: [`(org-read-date nil nil "+0d")`]
| Last update: [`(org-read-date nil nil "+0d")`]
| #+BEGIN: columnview :hlines 1 :maxlevel 3 :id local
| | Customer | Product | Price | Qty$_1$ | Prob. | Value | Qty$_2$ | Potential |
| |--+-+---+-+---+---+-+---|
| | Hyundai  | VEGA| 1 |   1 |   0.5 |  5000 |   1 | 1 |
| #+TBLFM: \$6=\$3*\$4*\$5;%.0f::\$8=\$3*\$7;%.0f
| #+END:
|  Outcome
| $0
|  Contacts
| [[file:contacts.org::${9:surname}, ${10:name}][$10 $9]]
|  Documents   
:noexport:
|  Results 
:noexport:
| - [ ] Result
| - [ ] Link to following project
| - [ ] Ask for recommendations
| - [ ] Link to competitor(s)
| - [ ] Archiving (later) into external file
|  Log
`


Thus in general contacts.org is uses only for the contacts.  Projects
from salesprojects.org contain links to these contacts.  Links to
e-mails are stored in the sales projects (section Log) as well.

Regards
-- 
Michael Strey 
www.strey.biz

Re: [O] changed?

[James Harkins]

On Jan 10, 2013 11:40 AM, "Nick Dokos"  wrote:
> I get different behavior from what you describe, with Org-mode
> version 7.9.2 (release_7.9.2-948-gab17f9 @
> /home/nick/elisp/org-mode/lisp/) and also going back to the version you
> mention below and also 7.9.2 for good measure:
>
> M-S-right behaves as you describe (it demotes the current subtree) but
> M-right demotes all the headings in the region (nb: *not* subtrees
necessarily,
> unless the region encompasses the whole subtree).

You are... quite right. I got confused between the two.

Thanks :-)
hjh

Re: [O] Upgrade to org 7.9.3.: clock in/out and org-odt export

[Martin Butz]

Hi Jambunathan,

thanks for the information about your name. So now I know how I can 
adress you - and not your father;)


As to the other very detailed infos about org-odt-export: Right now I 
have some work to do, but will have a closer look probably next week...


Thanks a lot
Martin

Am 09.01.2013 21:19, schrieb Jambunathan K:

Martin Butz  writes:


Hello K. Jambunathan,

(I guess Jambunathan is your sirname, but do not want to call you just
"K").


No, don't do that :-).  You will be addressing my father.

Confusion is arises because of differences in naming across cultures.

I live in India.  In the state where I am from (Tamilnadu), we usually
have just a single component to the name. i.e., there is no First,
Middle or Last names and I really don't know what a "Surname" is.

So "Jambunathan" is my given name.  "K" is my Father's name that is
abbreviated to just the initials.

People usually call me "Jambu".


one of the problems was my fault, I forgot to insert a
"#+end_quote". After completed the missing comment, all went well.

I encounter different problems, e.g. like an image link with missing
source.


Try to narrow it down and pass across a simple snippet to me.  I will be
happy to fix it.  You can also look at *Messages* buffer, you may get
some clues.


The exporter will not accept this. Also I had cases, where the
export will work, but LibreOffice will crash trying to load the
generated .odt-file. But I guess, this has nothing to do with org.


LibreOffice crashes usually when XML files are malformed.

If you don't have rnc files, (use M-x rng-what-schema RET while in an
XML file) then validation wouldn't catch errors. If you are running from
git, rnc files are installed for you and you can do the following right
within Emacs.

 1. C-x C-f test.odt.  Buffer will now be in archive-mode.
 2. RET on content.xml and/or any of the other XML files/
 3. C-c C-n. nXML will tell you where validation has failed.

This will give you clue on how to proceed further.  It is quite possible
that ODT exporter creates corrupt files.

You can also run the exported file through any of the OpenDOcument
validators in the cloud.  They seem to come and go.  So I will let you
google around, instead of providing any pointers.

See following node in the manual

 (info "(org) Validating OpenDocument XML")


In another case the content.xml of the gererated .odt had some not
closed elements (LibreOffice gave an error message), which I could fix
and then repack the archive.


You should report this issue.  I will be happy to fix.


I now do at least have some means to cope with problems. Thanks for
you help.





--

| G. Martin Butz, m...@mkblog.org, 0421 98749324, www.mkblog.org |

Re: [O] [BUG]HTML export convert line-break into a space

[Bastien]

Hi Rocky,

163(rockyzhz)  writes:

> As the title, HTML export would generate a extra space with the option:
> #+OPTIONS: \n:nil
> at the beginning of the org file.

I don't understand what the problem exactly is.

Can you give an example of an .org file and its .html export 
and point at what is wrong exactly in the HTML export?

Thanks,

-- 
 Bastien

Re: [O] Bug: Tag inheritance broken in agenda/timeline buffers [7.9.3a (release_7.9.3a-803-gf8f548 @ /home/horn/Repos/el/org-mode/lisp/)]

[Bastien]

Hi Tassilo,

Tassilo Horn  writes:

> I have (all default values)
>
>   org-use-tag-inheritance t
>   org-agenda-use-tag-inheritance '(todo search timeline agenda)
>   org-agenda-show-inherited-tags t
>
> but there are no inherited tags shown in the agenda or an org-buffer's
> timeline.
>
> When I press `T' on a agenda entry, the inherited tags are properly
> messaged in the echo area, though.

Yes, I'm aware this change/regression should be fixed, I will fix
it as soon as I have more time.

Thanks,

-- 
 Bastien

Re: [O] org-agenda-time-grid with org-agenda-prefix-format

[Bastien]

Hi Aaron,

can you repost your email using plain text?  AFAIK there is no global 
option for turning plain text on by default on gmail (shame on Google)
but you can do this for one email.

Otherwise your config is unreadable.

Also, please include a minimal example .org file to reproduce the bug
together with Org and Emacs version you are using.

Best,

-- 
 Bastien

Re: [O] org-id garbage collection?

[Bastien]

Hi James,

James Harkins  writes:

> Ok... and the behavior of org-id-update-id-locations? Does it remove
> ids that aren't found in any of the org files?
>
> I guess if I have time tonight, I can parse the old and new locations
> files and compare the keys. I was hoping someone would know and save
> me the trouble.

Please let us know, and thanks in advance for your time!

-- 
 Bastien

Re: [O] C / C++ standard org file

[Noah Eli Abrams]

Is PDF to org supposed to work? I tried their CLI commands and it just
produced an empty .org file.

[O] bug#13396: 24.2; org-agenda-include-diary doesn't work while using diary-file-name-prefix and diary-file-name-prefix-function elsewhere / FIX included

[Bastien]

Hi Andreas,

Thanks for the detailed report and the suggested fix.  
This is now fixed in Org's repository, it will be fixed
in Emacs when Org is merged again in emacs-24 branch.

Best regards,

-- 
 Bastien

Re: [O] C / C++ standard org file

[Bastien]

Please be more explicit about what you tried.

-- 
 Bastien

[O] org-element.el doesn't support interpreting repeating range timestamps

[Jonas Hörsch]

hej,

i just noticed, that although org-element properly parses the repeating
information of an active-range :type timestamp, it is not able to
interpret it again (unless the :raw-value is still present, of course).

minimal working example below:


* ❢ Tagesschau
<2013-01-15 Tue 20:00 +1d>--<2013-01-15 Tue 20:15 +1d>

* Parsing
#+name: timestamp
#+begin_src emacs-lisp
(org-element-put-property
 (org-element-put-property
  (org-element-map (org-element-parse-buffer) 'timestamp 'identity nil t)
  :parent nil)   ; so we don't clutter the output uselessly
 :raw-value nil) ; with raw-value it works, trivially
#+end_src

#+RESULTS: timestamp
| timestamp | (:type active-range :raw-value nil :year-start 2013 :month-start 1 :day-start 15 :hour-start 20 :minute-start 0 :year-end 2013 :month-end 1 :day-end 15 :hour-end 20 :minute-end 15 :begin 17 :end 71 :post-blank 0 :repeater-type cumulate :repeater-value 1 :repeater-unit day :parent nil) |

* Interpreting
#+begin_src emacs-lisp :var elem=timestamp
(org-element-interpret-data elem)
#+end_src

#+RESULTS:
: <2013-01-15 Tue 20:00>--<2013-01-15 Tue 20:15>


cheers,
jonas

[O] 回复: Re: [BUG]HTML export convert line-break into a space

[rockyzhz]

Hi Bastien,

For example, the org file(between the two lines) is:
--
#+OPTIONS: \n:nil

Example

abcde
fghijk
--
Then:
C-c C-e h

In HTML file, you will see that there is a space between the two strings:
abcde fghijk

This result is natural and good in English, but in Chinese
these is NOT any space among words typically, the extra space
converted from line-break would seem weird and somewhat ugly.

So could you provide an option for Chinese to avoid the extra space?

Thanks,

Rocky Zhang

From: Bastien
Date: 2013-01-10 18:43
To: rockyzhz
CC: emacs-orgmode
Subject: Re: [O] [BUG]HTML export convert line-break into a space
Hi Rocky,

163(rockyzhz)  writes:

> As the title, HTML export would generate a extra space with the option:
> #+OPTIONS: \n:nil
> at the beginning of the org file.

I don't understand what the problem exactly is.

Can you give an example of an .org file and its .html export 
and point at what is wrong exactly in the HTML export?

Thanks,

-- 
 Bastien

Re: [O] org-element.el doesn't support interpreting repeating range timestamps

[Nicolas Goaziou]

Hello,

co...@online.de (Jonas Hörsch) writes:

> i just noticed, that although org-element properly parses the repeating
> information of an active-range :type timestamp, it is not able to
> interpret it again (unless the :raw-value is still present, of
> course).

Fixed. Thank you for the detailed report.


Regards,

-- 
Nicolas Goaziou

Re: [O] A mail client that is org-mode compatible

[Suvayu Ali]

Hello Viktor and Igor,

Sorry for the late response, I was on holidays.

On Wed, Jan 02, 2013 at 01:38:40PM +0100, Viktor Rosenfeld wrote:
> Suvayu Ali wrote:
>
> > On Mon, Dec 31, 2012 at 08:29:12AM +0100, Gour wrote:
> >
> > I use notmuch for indexing only, and read and send emails from mutt.
> > Although I do not use gnus, I do use emacs as my editor (hence
> > message-mode) to compose emails; there I find Org is supported rather
> > well.  For linking to emails, I have been using org-notmuch quite
> > successfully for the last year now.
> >
> > If you are interested, feel free to ask I can share more details.
>
> I'm interested in your mutt+notmuch setup.

Syncing:

I use offlineimap to sync my Gmail account to a maildir.  The
configuration for this part is pretty basic.  In my offlineimap
postsynchook, I call `notmuch new`.  This indexes new emails.  I do this
every 5 minutes via a cron job (script attached).


Indexing:

Now my notmuch has a post-new hook which updates the tags I want to set.
It is basically a sequence of

  notmuch tag - --   # to remove tags
  notmuch tag + --   # to add tags

To make date based queries I use something like this

  $(($(date +%s) - )

in the query, e.g.  can be 604800 to specify one week ago.
This post-new hook is just the shell script /hooks/post-new.


Reading & responding to emails:

To make notmuch queries from mutt I use the excellent mutt fork, mutt-kz
.  I have managed to package it for
fedora replacing mutt from the repositories (spec file attached).

The README.notmuch in the repository above is pretty clear and concise.
Other than the interactive search it offers, I have also written a shell
script to filter threads by message-id or subject (attached).

I use emacsclient to respond.  I have not customised message-mode,
mostly due to lack of time.  So far I find the defaults are quite
acceptable, so I am not that motivated to customise just yet :-p.


Browsing, searching and linking to emails:

I can use the notmuch emacs client to browse and search through the
email archives (try M-x notmuch or M-x notmuch-search).  There is also a
very nice contributed library called notmuch-pick that offers a rather
nice threaded view.

To link to emails from Org mode, I use the library org-notmuch from
org-mode/contrib.  To use, just add contrib to the load-path and
require.  Now you can store a link to emails with org-store-link while
viewing it in the notmuch emacs client and insert the link later with
org-insert-link or org-insert-link-global.  As far I have noticed, it
can link to specific messages in threads, not just threads.


Caveat:

I have noticed sometimes the notmuch emacs client barfs at html email
sent from broken clients.  That said I did notice the latest version of
notmuch (0.15) address html email issues by being able to choose
specific MIME types to view for multipart messages.  Here is a quote
from the NEWS file:

  Visibility of MIME parts can be toggled

Each part of a multi-part MIME email can now be shown or hidden
using the button at the top of each part (by pressing RET on it or
by clicking).  For emails with multiple alternative formats (e.g.,
plain text and HTML), only the preferred format is shown initially,
but other formats can be shown using their part buttons.  To control
the behavior of this, see
`notmuch-multipart/alternative-discouraged` and
`notmuch-show-all-multipart/alternative-parts`.


Hopefully I have given enough information about my setup.

GL,

--
Suvayu

Open source is the future. It sets us free.
#!/bin/bash

# set -o xtrace

# return null string when filename expansion fails
shopt -s nullglob

declare cdir=$HOME/.offlineimap opts=("$@")
declare logfile=$cdir/log lockfile=($cdir/*lock) timestamp=$(date "+%F %T %Z")

exec 2>&1
exec >> $logfile

# clean-up past runs
[[ -e $lockfile ]] && rm $lockfile && \
echo "$timestamp: Cleaning up lock file $lockfile"

# sync with Gmail if imap server is reachable
nc -z imap.gmail.com 993 &> /dev/null && {
echo "$timestamp: Syncing with Gmail";
offlineimap "${opts[@]}";
}
#!/bin/bash

## Usage: Mutt macros to use this script
#
# macro index,pager"filter-mutt-thread id > 
/tmp/mutt-search-500\
# source /tmp/mutt-search-500" "Collate entire thread by 
message id"
#
# macro index,pager"filter-mutt-thread subject > 
/tmp/mutt-search-500\
# source /tmp/mutt-search-500" "Collate entire thread by 
subject"


# set -o xtrace

# leave tmp file management to caller
# TMPFILE=$(mktemp --tmpdir=/tmp mutt-search-$UID-)

declare query="$1" hdr regex match

case "$query" in
id)
hdr=Message-ID
;;
subject)
hdr=Subject
;;
*)
echo "Unknown option"
exit -1
esac

match=$(formail -z -x $hdr | tr -d '<>')

echo "push ' ${query}:\"$match\"&type=threads'"
%global git 51a28736
%bcond_without debug
%bcond_without imap
%bcond_without pop
%bcond_without 

Re: [O] 回复: Re: [BUG]HTML export convert line-break into a space

[Bastien]

Hi Rocky,

163(rockyzhz)  writes:

> This result is natural and good in English, but in Chinese
> these is NOT any space among words typically, the extra space
> converted from line-break would seem weird and somewhat ugly.
>
> So could you provide an option for Chinese to avoid the extra space?

This is not feasible with the current exporter.

But we might do this with the exporter for 8.0, I'll add
this on my TODO list.

Thanks,

-- 
 Bastien

Re: [O] A mail client that is org-mode compatible

[Igor Sosa Mayor]

Am Thu, Jan 10, 2013 at 02:47:17PM +0100, Suvayu Ali wrote:

> Sorry for the late response, I was on holidays.

thanks a lot for your informative answer! Very interesting!

-- 
:: Igor Sosa Mayor :: joseleopoldo1...@gmail.com ::
:: GnuPG: 0x1C1E2890   :: http://www.gnupg.org/  ::
:: jabberid: rogorido  ::::


pgptIYO3avkVk.pgp
Description: PGP signature

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

[Eric Schulte]

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 Gratz 
Date:   Sun Jan 6 18:24:56 2013 +0100

Compatibility: Use org-load-noerror-mustsuffix

* lisp/org-macs.el: New macro to allow the 5-argument form of load to
  be used where possible without breaking compatibility with XEmacs.

* lisp/org.el (org-version, org-reload): Use
  `org-load-noerror-mustsuffix´ instead of adding a fifth argument to
  load directly.  Guard against undefined variable load-suffixes,
  which doesn't exist in XEmacs.

Since load-suffixes doesn't exist in XEmacs, (org-reload 'uncompiled)
will not work.  If it doesn't complicate the compatibility macro too
much this can be added later.


-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

[Bastien]

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/lisp/org-macs.el
index e5d6100..974a366 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -426,6 +426,7 @@ the value in cdr."
 (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)

-- 
 Bastien

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

[Eric Schulte]

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 `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?

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

[Bastien]

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
required in org.el.

-- 
 Bastien

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

[Eric Schulte]

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' is part of org-macs.el which is
> required in org.el.

The attached init.el is sufficient to trip this error (note: I do have a
recent Org-mode version installed through ELPA, which is initialized
before the init.el is run).



init.el
Description: application/emacs-lisp

Sadly I have no backtrace to share, even starting with --debug-init, I
only get the following in my *Messages* buffer (and no *Backtrace*
buffer).

  let: Symbol's function definition is void: org-load-noerror-mustsuffix

Hope this helps,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

[Nick Dokos]

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 'org)?
> >
> > `org-load-noerror-mustsuffix' is part of org-macs.el which is
> > required in org.el.
> 
> The attached init.el is sufficient to trip this error (note: I do have a
> recent Org-mode version installed through ELPA, which is initialized
> before the init.el is run).
> 
> (add-hook 'after-init-hook
>  `(lambda ()
> (require 'org)
> (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
> (org-reload)))
> 
> Sadly I have no backtrace to share, even starting with --debug-init, I
> only get the following in my *Messages* buffer (and no *Backtrace*
> buffer).
> 
>   let: Symbol's function definition is void: org-load-noerror-mustsuffix
> 

So, which org-macs are you loading? If the (require 'org) loads the ELPA
org-macs (which presumably does not have the macro), then the (load-file
...) will not reload it (and even if it did, it would probably get the
ELPA one again). What happens if, after the (require 'org), you delete
org-macs from the features list, set the load path to pick up things
from ~/.emacs.d/src/org-mode/lisp, load org.el and then try the
org-reload?

Nick

Re: [O] How to add content from a file to a table automatically

[Darlan Cavalcante Moreira]

Thank you Eric and Jambunathan for your answers.

If I process the whole table with babel to manually add the lines from the
external file than I would have to take care of updating the formula for
the "Total" value as well as making sure the new content was added before
the "Total" line, right?. The later is simple, but updating the formula
could be complicated.

Meanwhile, I'm investigating using org-capture for this.

For instance, if I use a template such as
#+begin_src emacs-lisp
  ("f" "test" table-line
   (file+headline "test.org" "Test table")
   (file "path/food.org")
   :table-line-pos "II-1"
   :immediate-finish t)
#+end_src
where the food.org file has a single line then I can capture with
#+begin_src emacs-lisp
  (org-capture nil "f")'
#+end_src
and org-capture will place the content from the "food.org" file in a table
in the "Test Table" headline of the test.org file.

The advantage of using org-capture instead of pure babel is that it will
already put the content in the correct place and update the
formulas. However, the formulas are updated correctly only if I capture a
single line each time.

I think a combination of babel with org-capture is my best option.
Once that is working I will use your timer approach for automating this
(while I investigate inotify suggested by Jambunathan).

--
Darlan


At Wed, 09 Jan 2013 22:10:37 -0700,
Eric Schulte wrote:
> 
> #+Title: Periodically Rerun a Code Block
> 
> Here's the lisp code to define a function to continually re-run a code
> block.  Evaluate the following code block, then =M-x continually-run=,
> press ENTER and then type in the name of the code block to continually
> run (in this case "date").
> #+begin_src emacs-lisp :results silent
>   (defvar continual-runners nil
> "Holds running block timers (so they may be canceled).")
>   
>   (defun run-block-in-buffer (name buffer)
> (save-match-data
>   (with-current-buffer buffer
> (save-excursion
>   (org-babel-goto-named-src-block name)
>   (with-local-quit
> (undo-boundary)
> (with-temp-message (format "re-running %s" name)
>   (org-babel-execute-src-block))
> (undo-boundary))
>   
>   (defun continually-run (name)
> "Continually run the supplied code block name.
>   The code block is assumed to be in the current buffer."
> (interactive "scode block to continually run: ")
> (let ((run-buffer (current-buffer)))
>   (add-to-list 'continual-runners
>(run-at-time nil 5 'run-block-in-buffer name run-buffer
> #+end_src
> 
> Here's the code block to be continually re-run.
> #+Name: date
> #+begin_src sh
>   date
> #+end_src
> 
> And here are the results which will be continually updated.
> #+RESULTS: date
> : Wed Jan  9 22:04:08 MST 2013
> 
> Execute the following to stop all continually updating code blocks.
> #+begin_src emacs-lisp :results silent
>   (mapc #'cancel-timer continual-runners)
> #+end_src

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

[Eric Schulte]

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 Org function called before (require 'org)?
>> >
>> > `org-load-noerror-mustsuffix' is part of org-macs.el which is
>> > required in org.el.
>> 
>> The attached init.el is sufficient to trip this error (note: I do have a
>> recent Org-mode version installed through ELPA, which is initialized
>> before the init.el is run).
>> 
>> (add-hook 'after-init-hook
>>  `(lambda ()
>> (require 'org)
>> (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>> (org-reload)))
>> 
>> Sadly I have no backtrace to share, even starting with --debug-init, I
>> only get the following in my *Messages* buffer (and no *Backtrace*
>> buffer).
>> 
>>   let: Symbol's function definition is void: org-load-noerror-mustsuffix
>> 
>
> So, which org-macs are you loading? If the (require 'org) loads the ELPA
> org-macs (which presumably does not have the macro), then the (load-file
> ...) will not reload it (and even if it did, it would probably get the
> ELPA one again). What happens if, after the (require 'org), you delete
> org-macs from the features list, set the load path to pick up things
> from ~/.emacs.d/src/org-mode/lisp, load org.el and then try the
> org-reload?
>

I attempted to apply your suggestions to my init.el resulting in the
following



init.el
Description: application/emacs-lisp

It yields these errors on startup

  *Messages*
  Loading /home/eschulte/.emacs.d/src/org-mode/lisp/org.el (source)...
  Package assoc is obsolete!
  Loading /home/eschulte/.emacs.d/elpa/org-20121231/org-loaddefs.el 
(source)...done
  Problems while trying to load feature `org-jsinfo'
  eval-buffer: Symbol's function definition is void: 
org-define-obsolete-function-alias

It looks like removing items from `features' is dangerous.

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, and I don't think side-by-side
ELPA and source Org-modes are necessarily something that needs to be
supported.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] How to add content from a file to a table automatically

[Eric Schulte]

Darlan Cavalcante Moreira  writes:

> Thank you Eric and Jambunathan for your answers.
>
> If I process the whole table with babel to manually add the lines from the
> external file than I would have to take care of updating the formula for
> the "Total" value as well as making sure the new content was added before
> the "Total" line, right?. The later is simple, but updating the formula
> could be complicated.
>

Alternately, since the table is simply an array you could pass it to
another code block in your preferred language, and then perform the
total calculation on the array.  Then run `continually-run' on this
second code block.

>
> Meanwhile, I'm investigating using org-capture for this.
>

I'm not familiar with Org-capture myself, but the below sounds like a
good plan, I hope it works out.

If you do find a natural way to combine org-capture and Babel code
blocks I'm sure such a system would be of use to others on the list, so
please do share.

Best,

>
> For instance, if I use a template such as
> #+begin_src emacs-lisp
>   ("f" "test" table-line
>(file+headline "test.org" "Test table")
>(file "path/food.org")
>:table-line-pos "II-1"
>:immediate-finish t)
> #+end_src
> where the food.org file has a single line then I can capture with
> #+begin_src emacs-lisp
>   (org-capture nil "f")'
> #+end_src
> and org-capture will place the content from the "food.org" file in a table
> in the "Test Table" headline of the test.org file.
>
> The advantage of using org-capture instead of pure babel is that it will
> already put the content in the correct place and update the
> formulas. However, the formulas are updated correctly only if I capture a
> single line each time.
>
> I think a combination of babel with org-capture is my best option.
> Once that is working I will use your timer approach for automating this
> (while I investigate inotify suggested by Jambunathan).
>
> --
> Darlan
>
>
> At Wed, 09 Jan 2013 22:10:37 -0700,
> Eric Schulte wrote:
>> 
>> #+Title: Periodically Rerun a Code Block
>> 
>> Here's the lisp code to define a function to continually re-run a code
>> block.  Evaluate the following code block, then =M-x continually-run=,
>> press ENTER and then type in the name of the code block to continually
>> run (in this case "date").
>> #+begin_src emacs-lisp :results silent
>>   (defvar continual-runners nil
>> "Holds running block timers (so they may be canceled).")
>>   
>>   (defun run-block-in-buffer (name buffer)
>> (save-match-data
>>   (with-current-buffer buffer
>> (save-excursion
>>   (org-babel-goto-named-src-block name)
>>   (with-local-quit
>> (undo-boundary)
>> (with-temp-message (format "re-running %s" name)
>>   (org-babel-execute-src-block))
>> (undo-boundary))
>>   
>>   (defun continually-run (name)
>> "Continually run the supplied code block name.
>>   The code block is assumed to be in the current buffer."
>> (interactive "scode block to continually run: ")
>> (let ((run-buffer (current-buffer)))
>>   (add-to-list 'continual-runners
>>(run-at-time nil 5 'run-block-in-buffer name 
>> run-buffer
>> #+end_src
>> 
>> Here's the code block to be continually re-run.
>> #+Name: date
>> #+begin_src sh
>>   date
>> #+end_src
>> 
>> And here are the results which will be continually updated.
>> #+RESULTS: date
>> : Wed Jan  9 22:04:08 MST 2013
>> 
>> Execute the following to stop all continually updating code blocks.
>> #+begin_src emacs-lisp :results silent
>>   (mapc #'cancel-timer continual-runners)
>> #+end_src

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] A mail client that is org-mode compatible

[Viktor Rosenfeld]

thanks, very informative!

Suvayu Ali wrote:

> Sorry for the late response, I was on holidays.

Re: [O] org-e-latex: ignoreheading is not working any more.

[Sebastian Hofer]

At Thu, 10 Jan 2013 19:44:32 +0100,
Nicolas Goaziou wrote:
> 
> Hello,
> 
> Sebastian Hofer  writes:
> 
> > #+BEGIN_SRC emacs-lisp
> > (defun my-e-latex-headline (headline contents info)
> >   (if (member "ignoreheading" (org-element-property :tags headline)) 
> > contents
> > (org-e-latex-headline headline contents info)))
> > #+END_SRC
> 
> I suggest to use:
> 
>   (org-export-with-backend 'e-latex headline contents info)
> 
> instead of
> 
>   (org-e-latex-headline headline contents info)
> 
> to not depend on the name of the translator function used by the e-latex
> back-end.
> 
> > #+BEGIN_SRC emacs-lisp
> > (org-export-define-derived-backend dissertation e-latex
> >   :translate-alist ((template . my-e-latex-headline)))
> 
> There's a typo here. It should be:
> 
> :translate-alist ((headline . my-e-latex-headline))

That worked perfectly! Thanks!

Regards,
Sebastian

Re: [O] Usecase for inotify? Re: How to add content from a file to a table automatically

[Eli Zaretskii]

> From: Jambunathan K 
> Date: Thu, 10 Jan 2013 10:37:19 +0530
> Cc: emacs-orgmode , emacs-de...@gnu.org
> 
> 
> There is support for inotify in Emacs.  Last I heard, people were
> interested in hearing use-cases.
> 
> I am not sure it qualifies as a minimal use-case.  But it is something
> that comes out of real life.  So here it goes to emacs-devel...

Thanks.

However, at least from my perspective, a useful use case should
include a description of how a feature was actually implemented using
the file notification, how the provided APIs were used to implement
it, and what experience and suggestions for API modifications were
gained as result.

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

[Eric Schulte]

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 questions on the mailing list, and I don't think side-by-side
>> ELPA and source Org-modes are necessarily something that needs to be
>> supported.
>
> I confirm `org-load-noerror-mustsuffix' is *not* in the ELPA tarball,
> so somehow your initialization (auto)loads recent Org files, and then
> the ELPA load path takes over.
>
> As said in http://orgmode.org/elpa.html:
>
> ,
> | By default, Emacs loads packages after it loads your Emacs init file.
> | 
> | We recommend intializing packages as early as possible in your Emacs
> | init file so that your Org configuration will be correctly handled:
> | 
> | ;; -*- emacs-lisp -*-
> | (package-initialize);; Initialize & Install Package
> | ;; (setq org-...)   ;; Your custom settings
> | 
> | The package initialization should happen before you require Org and
> | set any Org options.
> `
>
> So yes, I'd suggest removing Org ELPA version completely..

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.el with the attached (update paths as appropriate)



init.el
Description: application/emacs-lisp

3. start Emacs

For me this minimal setup works with versions of Org-mode prior to
5484a33b, but fails with the current master branch.

As a side note, is it intended that users should have to load
org-compat.el before loading org.el?

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

[Achim Gratz]

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 no
autoloads generated in the Git work tree:

--8<---cut here---start->8---
  *Messages*
  Loading /home/eschulte/.emacs.d/src/org-mode/lisp/org.el (source)...
  Package assoc is obsolete!
  Loading /home/eschulte/.emacs.d/elpa/org-20121231/org-loaddefs.el 
(source)...done
  Problems while trying to load feature `org-jsinfo'
  eval-buffer: Symbol's function definition is void: 
org-define-obsolete-function-alias
--8<---cut here---end--->8---

This makes Emacs pick up the (wrong) autoloads from the ELPA directory,
although the root cause for your failure is that Org has been partly
loaded before the load-path were pointing to the Git work tree and other
parts have been loaded after the load-path changed.  Please remove or
deactivate the ELPA package.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

[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, and I don't think side-by-side
> ELPA and source Org-modes are necessarily something that needs to be
> supported.

I confirm `org-load-noerror-mustsuffix' is *not* in the ELPA tarball,
so somehow your initialization (auto)loads recent Org files, and then
the ELPA load path takes over.

As said in http://orgmode.org/elpa.html:

,
| By default, Emacs loads packages after it loads your Emacs init file.
| 
| We recommend intializing packages as early as possible in your Emacs
| init file so that your Org configuration will be correctly handled:
| 
| ;; -*- emacs-lisp -*-
| (package-initialize);; Initialize & Install Package
| ;; (setq org-...)   ;; Your custom settings
| 
| The package initialization should happen before you require Org and
| set any Org options.
`

So yes, I'd suggest removing Org ELPA version completely..

-- 
 Bastien

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

[Bastien]

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

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

[Achim Gratz]

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.el with the attached (update paths as appropriate)
>
> (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")
> (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>
> 3. start Emacs
>
> For me this minimal setup works with versions of Org-mode prior to
> 5484a33b, but fails with the current master branch.

Which version of Emacs, any old org-remnants in site-lisp and where do
you set load-path?  It would be easier for all of us if you could do a
step-by-step evaluation in the scratch buffer from "emacs -Q".


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

[Eric Schulte]

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,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

[Nicolas Goaziou]

Hello,

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

Thanks for your patch. A few comments below.

> I don't think I fully understand how :options-alist works.  With the
> attached patch I was expecting to be able to use #+LATEX_HYPER: nil, but
> this didn't work for me.

Keywords values are either a string or a list of strings. In this case,
#+LATEX_HYPER: nil means the value is "nil", not nil.

You still can test it with `org-not-nil' function.

>:options-alist ((:date "DATE" nil org-e-latex-date-format t)
> (:latex-class "LATEX_CLASS" nil org-e-latex-default-class t)
> (:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t)
> -   (:latex-header-extra "LATEX_HEADER" nil nil newline)))
> +   (:latex-header-extra "LATEX_HEADER" nil nil newline)
> +   (:with-hyper "LATEX_HYPER" "texht" t t)

I suggest to use :latex-hyperref-p or :latex-with-hyperref instead
of :with-hyper, since this is back-end specific.

Moreover, IMO, it doesn't make sense to provide a way to set it both
through the #+OPTIONS: line and with a "LATEX_HYPER" keyword. You should
choose your side.

Also, you may want to use a global defcustom for the default value,
instead of setting it to t, i.e. `org-e-latex-with-hyperref'.

> +   ))

Please do not leave parenthesis on a line of their own.


Regards,

-- 
Nicolas Goaziou

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

[Paul Sexton]

org-capture-templates-contexts currently appears not to work. The structure
that the function 'org-contextualize-validate-key' expects to find in the
variable seems quite different from the structure described in the docstring.

Here are fixed versions of the functions 'org-contextualize-validate-key'
and 'org-contextualize-keys', both from org.el. I have also added some
functionality:
- 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.

I have also rewritten the docstring for org-capture-templates-contexts,
from org-capture.el.




(defcustom org-capture-templates-contexts nil
  "Alist of capture templates and valid contexts.

Each entry in the alist takes the form:
   (KEY [USUAL-KEY] CONTEXT [CONTEXT...])

Where:
   KEY :: a string of one or more letters, identifying a
   capture template.
   USUAL-KEY :: if supplied, this is the string that identifies
   the capture template in `org-capture-templates', while KEY
   becomes the string which will be used to select the
   template only in the present context (see below).
   CONTEXT :: a context definition.

Each context definition (CONTEXT) takes the form:
   FUNCTION
   or  (SPECIFIER . ARGUMENT)

Where:
   FUNCTION :: either a lambda form or a symbol naming a function.
  The function must take no arguments.
   SPECIFIER :: a symbol matching one of the context specifiers listed
  below.
   ARGUMENT :: either a string regular expression (for in-file and
  in-buffer), or a symbol (for in-mode).

Here are the available context specifiers:

  in-file: command displayed in files matching regex
in-buffer: command displayed in buffers matching regex
  in-mode: command displayed if major mode matches symbol
  not-in-file: command not displayed in files matching regex
not-in-buffer: command not displayed in buffers matching regex
  not-in-mode: command not displayed when major mode matches symbol

For example, if you have a capture template \"c\" and you want
this template to be accessible only from `message-mode' buffers,
use this:

   '((\"c\" (in-mode . message-mode)))

If you include several context definitions, the agenda command
will be accessible if at least one of them is valid.

If the template specified by KEY has sub-templates, they will also
be affected by the rule (unless they have their own rules). For
example, if you have a template `t' and sub-templates `ta', `tb'
and `tc', then a rule for `t' will affect whether all of those
contexts are accessible.

You can also bind a key to another agenda custom command
depending on contextual rules.

'((\"c\" \"d\" (in-file . \"\\.el$\") (in-buffer \"scratch\")))

Here it means: in files ending in `.el' and in buffers whose
name contains `scratch', use \"c\" as the
key for the capture template otherwise associated with \"d\".
\(The template originally associated with \"q\" is not displayed
to avoid duplicates.)"
  :version "24.3"
  :group 'org-capture
  :type '(repeat (list :tag "Rule"
   (string :tag "Capture key")
   (string :tag "Replace by template")
   (repeat :tag "Available when"
  (choice
   (cons :tag "Condition"
 (choice
  (const :tag "In file" in-file)
  (const :tag "Not in file" not-in-file)
  (const :tag "In mode" in-mode)
  (const :tag "Not in mode" not-in-mode))
 (regexp))
   (function :tag "Custom function"))


(defun org-contextualize-validate-key (key contexts)
  "Check CONTEXTS for agenda or capture KEY."
  (let (clause context res)
(while (setq clause (pop contexts))
  (destructuring-bind (context-key old-key . context-list) clause
(mapc
 (lambda (context)
   (when
   (cond
((and (>= (length context-key) (length key))
  (not (equal key context-key)))
 nil)
((and (< (length context-key) (length key))
  (not (string-prefix-p context-key key)))
 nil)
((functionp context)
 (funcall context))
(t
 (destructuring-bind (context-spec . context-arg) context
   (message "Considering context %s" context)
   (or (and (eq context-spec 'in-file)
(buffer-file-name)
(string-match contex

Re: [O] org-e-latex: ignoreheading is not working any more.

[Nicolas Goaziou]

Hello,

Sebastian Hofer  writes:

> #+BEGIN_SRC emacs-lisp
> (defun my-e-latex-headline (headline contents info)
>   (if (member "ignoreheading" (org-element-property :tags headline)) contents
> (org-e-latex-headline headline contents info)))
> #+END_SRC

I suggest to use:

  (org-export-with-backend 'e-latex headline contents info)

instead of

  (org-e-latex-headline headline contents info)

to not depend on the name of the translator function used by the e-latex
back-end.

> #+BEGIN_SRC emacs-lisp
> (org-export-define-derived-backend dissertation e-latex
>   :translate-alist ((template . my-e-latex-headline)))

There's a typo here. It should be:

:translate-alist ((headline . my-e-latex-headline))


Regards,

-- 
Nicolas Goaziou

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

[Eric Schulte]

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 earlier.
>

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-iterate, with no Org-mode installed
through ELPA, and with a clean (either with or without running make)
checkout of the master branch start up an "Emacs -Q", and then evaluate
the following in your scratch buffer.

  (load-file "path/to/org-mode/lisp/org.el")

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

[Eric Schulte]

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 locate
>>
>> 2. replace your init.el with the attached (update paths as appropriate)
>>
>> (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")
>> (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
>>
>> 3. start Emacs
>>
>> For me this minimal setup works with versions of Org-mode prior to
>> 5484a33b, but fails with the current master branch.
>
> Which version of Emacs,

Fairly recent from the bzr repository.

GNU Emacs 24.3.50.1
Copyright (C) 2012 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

> any old org-remnants in site-lisp

No, only the Org-mode distributed as part of Emacs.

> and where do you set load-path?

No load path customization, just those two lines above are enough to
cause the error.

> It would be easier for all of us if you could do a step-by-step
> evaluation in the scratch buffer from "emacs -Q".
>

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

  (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")
  (load-file "~/.emacs.d/src/org-mode/lisp/org.el")

The above works prior to the offending commit, but now it throws an
error.

Can you reproduce this?

Thanks,

>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

[Bastien]

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, right?

> I'm surprised I'm the only person experiencing this problem.  Can anyone
> else reproduce this locally?  To re-iterate, with no Org-mode installed
> through ELPA, and with a clean (either with or without running make)
> checkout of the master branch start up an "Emacs -Q", and then evaluate
> the following in your scratch buffer.
>
>   (load-file "path/to/org-mode/lisp/org.el")

When you use Org from git, you need to run make autoloads at least.
Otherwise, yes, autoloads will not be correct.

-- 
 Bastien

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

[Stelian Iancu]

> 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-iterate, with no Org-mode installed
> through ELPA, and with a clean (either with or without running make)
> checkout of the master branch start up an "Emacs -Q", and then evaluate
> the following in your scratch buffer.
> 
>  (load-file "path/to/org-mode/lisp/org.el")
> 

I did exactly this and I get the following:

let: Symbol's function definition is void: org-load-noerror-mustsuffix

Latest code from git, did run make. 

Emacs is the latest pretest:

GNU Emacs 24.2.92.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 
2013-01-10 on bob.porkrind.org

Indeed, when doing (require 'org) I don't get this problem. So even though the 
latest code is in the load-path, somehow it's not loaded.

Stelian

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

[Stelian Iancu]

> 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-iterate, with no Org-mode installed
> through ELPA, and with a clean (either with or without running make)
> checkout of the master branch start up an "Emacs -Q", and then evaluate
> the following in your scratch buffer.
> 
>  (load-file "path/to/org-mode/lisp/org.el")
> 

I did exactly this and I get the following:

let: Symbol's function definition is void: org-load-noerror-mustsuffix

Latest code from git, did run make. 

Emacs is the latest pretest:

GNU Emacs 24.2.92.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 
2013-01-10 on bob.porkrind.org

Indeed, when doing (require 'org) I don't get this problem. So even though the 
latest code is in the load-path, somehow it's not loaded.

Stelian

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

[Nick Dokos]

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/")
> (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
> (org-reload)))
> 

> 
> It yields these errors on startup
> 
>   *Messages*
>   Loading /home/eschulte/.emacs.d/src/org-mode/lisp/org.el (source)...
>   Package assoc is obsolete!
>   Loading /home/eschulte/.emacs.d/elpa/org-20121231/org-loaddefs.el 
> (source)...done
>   Problems while trying to load feature `org-jsinfo'
>   eval-buffer: Symbol's function definition is void: 
> org-define-obsolete-function-alias
> 
> It looks like removing items from `features' is dangerous.
> 

I don't think so: I got the org-define-obsolete-function-alias error
when trying to org-reload this morning (resolved by manually loading
org-compat.el before doing the org-reload again): it's another instance
of the same problem.

You also don't seem to have an org-loaddefs.el in the git clone, so it
loads the one it finds in the ELPA dir. You should ``make autoloads''.

> 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, and I don't think side-by-side
> ELPA and source Org-modes are necessarily something that needs to be
> supported.
> 

I'm pretty sure it is. It would probably be better to have two separate
installations and have different init files for each. The side-by-side
installations is an invitation to a franken-install.

Nick

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

[Nick Dokos]

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
> 
>   (load-file "~/.emacs.d/src/org-mode/lisp/org-compat.el")
>   (load-file "~/.emacs.d/src/org-mode/lisp/org.el")
> 
> The above works prior to the offending commit, but now it throws an
> error.
> 

I doubt that it works in either case: it may not throw an error but you
still have a mixed install where most of the org stuff will come from
the org that's distributed with emacs.

> Can you reproduce this?
> 

I don't know what error you get: I get a recursive load

insert-file-contents: Recursive load: 
"/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
   "/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
"/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
 "/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
  
"/usr/local/share/emacs/24.3.50/lisp/jka-compr.el.gz",\
   
"/usr/local/share/emacs/24.3.50/lisp/emacs-lisp/debug.el.gz",\
"/home/nick/src/emacs/org/org-mode/lisp/org.el"

No idea why.

But as I said before, you can not expect this to work.

Nick

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

[Nick Dokos]

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 does indeed work, I should have tried it much earlier.
> >
> 
> 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.
> 

Count me confused: what does it do?

> I'm surprised I'm the only person experiencing this problem.  Can anyone
> else reproduce this locally?  To re-iterate, with no Org-mode installed
> through ELPA, and with a clean (either with or without running make)
> checkout of the master branch start up an "Emacs -Q", and then evaluate
> the following in your scratch buffer.
> 
>   (load-file "path/to/org-mode/lisp/org.el")
> 

This has no chance of working: it will satisfy all the requires from the
org that's distributed with emacs. You must ``make autoloads'' and you
must set the load-path.

Nick

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

[Eric Schulte]

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 about the missing function anymore, right?
>
>> I'm surprised I'm the only person experiencing this problem.  Can anyone
>> else reproduce this locally?  To re-iterate, with no Org-mode installed
>> through ELPA, and with a clean (either with or without running make)
>> checkout of the master branch start up an "Emacs -Q", and then evaluate
>> the following in your scratch buffer.
>>
>>   (load-file "path/to/org-mode/lisp/org.el")
>
> When you use Org from git, you need to run make autoloads at least.
> Otherwise, yes, autoloads will not be correct.

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.

I guess we inherited the need to run "make autoloads" when we got rid of
org-install.el?

Perhaps the Org-mode build [1] page (the target of the "installing Org
mode" link at the top of the home page) shouldn't start with the
sentence "Org can be run directly from sources".

Thanks,

Footnotes: 
[1]  http://orgmode.org/worg/dev/org-build-system.html

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

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

[Thomas S. Dye]

Aloha Nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> t...@tsdye.com (Thomas S. Dye) writes:
>
> Thanks for your patch. A few comments below.
>
>> I don't think I fully understand how :options-alist works.  With the
>> attached patch I was expecting to be able to use #+LATEX_HYPER: nil, but
>> this didn't work for me.
>
> Keywords values are either a string or a list of strings. In this case,
> #+LATEX_HYPER: nil means the value is "nil", not nil.
>
> You still can test it with `org-not-nil' function.
>
>>:options-alist ((:date "DATE" nil org-e-latex-date-format t)
>>(:latex-class "LATEX_CLASS" nil org-e-latex-default-class t)
>>(:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t)
>> -  (:latex-header-extra "LATEX_HEADER" nil nil newline)))
>> +  (:latex-header-extra "LATEX_HEADER" nil nil newline)
>> +  (:with-hyper "LATEX_HYPER" "texht" t t)
>
> I suggest to use :latex-hyperref-p or :latex-with-hyperref instead
> of :with-hyper, since this is back-end specific.
>
> Moreover, IMO, it doesn't make sense to provide a way to set it both
> through the #+OPTIONS: line and with a "LATEX_HYPER" keyword. You should
> choose your side.
>
> Also, you may want to use a global defcustom for the default value,
> instead of setting it to t, i.e. `org-e-latex-with-hyperref'.

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

All the best,
Tom

>From 4946aec91aa6de433beb1301c77ebbb8924a2404 Mon Sep 17 00:00:00 2001
From: Thomas Dye 
Date: Thu, 10 Jan 2013 14:06:18 -1000
Subject: [PATCH] New LaTeX exporter: Add an option to toggle insertion of
 \hypersetup{...} in preamble

* contrib/lisp/org-e-latex.el: Added an option, :texht, and a
  defcustom, org-e-latex-with-hyperref, to hold its default value.

It is possible to configure the exporter to omit the hyperref package,
which defines the \hypersetup{} command.
---
 contrib/lisp/org-e-latex.el | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/contrib/lisp/org-e-latex.el b/contrib/lisp/org-e-latex.el
index b8f8aa9..f394bc2 100644
--- a/contrib/lisp/org-e-latex.el
+++ b/contrib/lisp/org-e-latex.el
@@ -164,7 +164,8 @@
   :options-alist ((:date "DATE" nil org-e-latex-date-format t)
 		  (:latex-class "LATEX_CLASS" nil org-e-latex-default-class t)
 		  (:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t)
-		  (:latex-header-extra "LATEX_HEADER" nil nil newline)))
+		  (:latex-header-extra "LATEX_HEADER" nil nil newline)
+		  (:latex-hyperref-p nil "texht" org-e-latex-with-hyperref t)))
 
 
 
@@ -399,6 +400,11 @@ toc:nil option, not to those generated with #+TOC keyword."
   :group 'org-export-e-latex
   :type 'string)
 
+(defcustom org-e-latex-with-hyperref t
+  "Toggle insertion of \hypersetup{...} in the preamble."
+  :group 'org-export-e-latex
+  :type 'boolean)
+
  Headline
 
 (defcustom org-e-latex-format-headline-function nil
@@ -1117,11 +1123,12 @@ holding export options."
  ;; Title
  (format "\\title{%s}\n" title)
  ;; Hyperref options.
- (format "\\hypersetup{\n  pdfkeywords={%s},\n  pdfsubject={%s},\n  pdfcreator={%s}}\n"
-	 (or (plist-get info :keywords) "")
-	 (or (plist-get info :description) "")
-	 (if (not (plist-get info :with-creator)) ""
-	   (plist-get info :creator)))
+ (when (plist-get info :latex-hyperref-p) 
+   (format "\\hypersetup{\n  pdfkeywords={%s},\n  pdfsubject={%s},\n  pdfcreator={%s}}\n"
+	   (or (plist-get info :keywords) "")
+	   (or (plist-get info :description) "")
+	   (if (not (plist-get info :with-creator)) ""
+		 (plist-get info :creator
  ;; Document start.
  "\\begin{document}\n\n"
  ;; Title command.
-- 
1.8.0.2



-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

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

[Stefan Monnier]

>> There is currently a problem with package manager when a package is
>> installed from a package archive,that package is already installed
>> either in Emacs core or site-lisp, and when (parts of) said package have
>> already been loaded when ELPA tries to install: the byte-compiler will
>> use the already loaded definitions rather than the new ones from the
>> package to install.
> I guess this would be http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125

Indeed, and as I mentioned back then I think it's a general enough
problem that we should try and think up a good solution.

Currently, we have two proposals:

1- run a separate Emacs instance: this gives you a clean slate, and lets
   you compile in parallel, but runs into the difficulty of figuring out
   exactly which clean slate to use.
   I guess we could fork Emacs early on and keep this second process
   around as a "process from which to generate new clean slates".

2- improve bytecomp.el to try and better isolate the compiled file from
   the previously loaded packages.

I don't see a clear winner, but since I'm biased in favor of the second
(not sure why, to tell you the truth), I'll add a few points related to
it.  The current behavior of bytecomp.el leads to various related
problems:
- outdated but already loaded packages can lead to mis-compilation.
  for the bootstrap we try to workaround this with
  byte-compile-refresh-preloaded, tho it only takes care of some
  particular cases.
- outdated .elc file taking precedence over the new .el file can do
  the same.
- bytecompiling a file affects the running session by side-effects such
  as requiring packages.
- if a package calls `byte-compile' during its own compilation, this
  sub-compilation will tend to complain about undeclared variables
  because it doesn't know about the vars that have been defvar'd in the
  outer compilation.  That's one of the main reasons for cc-bytecomp's
  hideous gymnastics.

Maybe we should (similarly to the fork idea above) keep a "clean
obarray", and run byte-compilations in a fresh copy of this
clean obarray.

I suggested a quick&dirty solution:
> > E.g. we could add to bytecomp.el the ability to force `require' to
> > reload a package if it's not already loaded from the file that
> > locate-library returns.

I still think it's not a bad option.

Of course, we'd still get trouble when the loading is not performed via
`require' but via autoload (maybe we could try and attack this problem
by allowing `autoload' to override an already existing definition, but
that could be delicate).

> That will probably work fine most of the time, but what if a package is
> restructed so that the feature names are different? Or a feature is
> removed?

I don't see why that would introduce a difficulty.


Stefan

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

[Jambunathan K]

Stefan Monnier  writes:

> - outdated .elc file taking precedence over the new .el file can do
>   the same.

I find this warning quite useful.

Consider this, all happening because of what is in .emacs.

1. Something in .emacs causes org-x to be loaded from Vanilla Emacs.

2. Load path changed to point to a git checkout.

3. User does something which loads org-y.  org-y comes from (2).  The
   chain of events ends up with requiring an org-x.  org-x WASN'T
   RE-LOADED because the symbol is provided.  Ofcourse, it is provided
   from the wrong place.

In case of (3), a warning that says "I refuse to have mutiple
personality disorder".   A warning during Emacs initing could be
missed.  So if there is a command line option to trigger an abrupt-end,
we could advise the user to enable it and say "You have got a problem in
your init file.  Not the Org-mode that is distributed."

This will serve to remove endless amount of confusion.

What I am saying, even if we couldn't solve the problem cleanly, a
simple warning that says "Something fishy" will greatly reduce the user
complaints in the Org list.

I am not sure how much of what I typed makes sense.  But I type
nevertheless, people read it or ignore it.
-- 

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

[Bastien]

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 this to work, 
or was it just because you used `make autoloads'?

> I guess we inherited the need to run "make autoloads" when we got rid of
> org-install.el?

Not really.  It was always needed to create autoloads (either in
org-install.el or now in org-loaddefs.el) when using Org from Git.

See `make autoloads' for Org 7.7 already creates org-install.el:
http://orgmode.org/cgit.cgi/org-mode.git/plain/Makefile?id=release_7.7

> Perhaps the Org-mode build [1] page (the target of the "installing Org
> mode" link at the top of the home page) shouldn't start with the
> sentence "Org can be run directly from sources".

Yes, I will update both the manual and the Worg page.  

Thanks!

-- 
 Bastien