Re: [O] Bug in pdf export of tables with latest development version

[Herbert Sitz]

Nick Dokos  hp.com> writes:
> 
> You probably should try using a long table: section 12.6.4 in the manual
> or evaluate
> 
> (info "(org) Tables in LaTeX export")
> 
> Nick
> 

Nick --- Thanks, that did the trick.  Sorry to trouble you, upgrading to 7.7
development version and could have sworn same thing worked fine in the 7.4 I was
using, but I'm sure I was mistaken. Thanks again.   --- Herb

Re: [O] [RFC] Standardized code block keywords

[Nick Dokos]

Thomas S. Dye  wrote:

> And, revising the files before Worg updates the Org-mode it uses will
> break them, right?

Yup - they got to be done at the same time.

Nick

> 
> Tom
> 
> Nick Dokos  writes:
> 
> > I'm trying to add a note to Worg hacks but before I push, I use my local
> > org setup to publish Worg locally and take a look at it (not entirely 
> > reliable
> > since my org version is usually different from the real Worg one, but a
> > good indication of problems before they happen nevertheless). I ran into
> > a couple of problems. 
> >
> > The first one is expected: I'm running with Eric's patch, so when
> > processing Worg/org-contrib/babel/examples/o18.org (Tom Dye's article on
> > Archaelogy in Oceania), I ran into #+srcname vs #+name problems: when
> > Eric's changes do go into org and the new org is used to publish Worg,
> > there is going to be some breakage. Actually, o18.org is the extent of
> > breakage that I saw, so it doesn't look too bad.
> >
> > But I also ran into a second (unrelated) issue. Here's a minimal example:
> >
> > * Conclusion
> >
> > #+begin_src latex 
> >
> > #+end_src
> >
> > Exporting to html gives me the attached backtrace. But the underlying reason
> > is easy to demonstrate: if you C-c C-c on the empty source block, you get:
> >
> > ,
> > | * Conclusion
> > | 
> > | #+begin_src latex 
> > | 
> > | #+end_src
> > | 
> > | #+results:
> > | #+END_LaTeX
> > | #+BEGIN_LaTeX
> > `
> >
> > Nick
> >
> > Versions:
> > Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
> > GNU Emacs 24.0.90.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 
> > 2011-10-27
> >
> >
> >
> 
> -- 
> Thomas S. Dye
> http://www.tsdye.com
> 

Re: [O] Bug in pdf export of tables with latest development version

[Nick Dokos]

Herbert Sitz  wrote:

> Herbert Sitz  gmail.com> writes:
> > I'm having problems exporting to pdf with a source block that generates a 
> table
> > result.  If the table has enough rows to get to bottom of page, it seems, 
> the
> > rest of the table output disappears/is discarded and the pdf document 
> skips to
> > text after the source block output.
> > 
> 
> A little more info.  Looking at the .tex file all of the exported data is 
> there
> in a \tabular section.  However as I said whatever goes beyond end of page 
> where
> table starts is discarded or invisible on conversion to pdf.  It seems no page
> breaks are getting put into the table, just runs off end of first page in pdf.
> 
> -- Herb
> 
> 

You probably should try using a long table: section 12.6.4 in the manual
or evaluate

(info "(org) Tables in LaTeX export")

Nick

Re: [O] Elisp programming style

[Eric Abrahamsen]

[...]


>> Would that be considered bad style from the original author, or is that
>> up to personal choice and not considered a problem?
>> 
>
> Not a problem - you can't predict the future. You do the best you can
> with your current knowledge. You can always refactor in the future:
> that's one reason that having the source code around is important.  When
> you refactor, you may be cursing the original author for the "bad"
> decicions, but c'est la vie: at least, you have chosen a system where
> *you* can do that and not depend on a third party: they might not even
> be alive, let alone willing to do what you want.

I think this is probably the key. As a non-professional programmer who
has gone on safari through the org-mode code (though this obviously
applies to a lot of elisp packages), I think incremental growth is
responsible for a lot of oddities. Refactoring is possible in theory,
but for fast-growing packages it never becomes a priority, and my guess
is by this point there are parts of org where even Carsten would tread
very lightly. It's not a disaster, but it does lead to regression bugs,
which I think we're seeing.

Entropy is contravened, however: witness the push towards an org test
suite, and the production of a generic exporter in org…

Slightly OT, sorry,

Eric

-- 
GNU Emacs 24.0.90.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4)
 of 2011-10-06 on pellet
Org-mode version 7.7 (release_7.7.466.ga5cb)

Re: [O] Bug in pdf export of tables with latest development version

[Herbert Sitz]

Herbert Sitz  gmail.com> writes:
> I'm having problems exporting to pdf with a source block that generates a 
table
> result.  If the table has enough rows to get to bottom of page, it seems, 
the
> rest of the table output disappears/is discarded and the pdf document 
skips to
> text after the source block output.
> 

A little more info.  Looking at the .tex file all of the exported data is there
in a \tabular section.  However as I said whatever goes beyond end of page where
table starts is discarded or invisible on conversion to pdf.  It seems no page
breaks are getting put into the table, just runs off end of first page in pdf.

-- Herb

[O] Bug in pdf export of tables with latest development version

[Herbert Sitz]

I'm having problems exporting to pdf with a source block that generates a table
result.  If the table has enough rows to get to bottom of page, it seems, the
rest of the table output disappears/is discarded and the pdf document skips to
text after the source block output.

Everything works fine with html output.

Here's sample code.  With repeat number of above 50 or so it will truncate table
output in resulting pdf:
--
* Head one

#+begin_src python :exports results :results value
mylist = []
for i in range(100):
mylist.append([i,i+1,i+2,i+3,i+4])
return str(mylist)
#+end_src

#+results:

* Head two
more text for head two
---

Re: [O] [odt] Support for annotations/comments

[Herbert Sitz]

Jambunathan K  gmail.com> writes:
> 
> I needed an excuse for adding support for annotations. Exporting the
> below org will produce the attached odt/pdf files. Note that the pdf
> file is produced by LibreOffice pdf export.
> 
> Annotations is a ODT only feature right now and will not work with other
> backends.
> 


Wow!  That's great.  I wasn't thinking of odt, have never used it, but 
maybe I will check into it.  I loaded into Word 2007 and it gave some 
error message but displayed the comments fine.  And of course they work 
great in the LibreOffice pdf.

Thanks,

Herb

Re: [O] [RFC] Standardized code block keywords

[Thomas S. Dye]

And, revising the files before Worg updates the Org-mode it uses will
break them, right?

Tom

Nick Dokos  writes:

> I'm trying to add a note to Worg hacks but before I push, I use my local
> org setup to publish Worg locally and take a look at it (not entirely reliable
> since my org version is usually different from the real Worg one, but a
> good indication of problems before they happen nevertheless). I ran into
> a couple of problems. 
>
> The first one is expected: I'm running with Eric's patch, so when
> processing Worg/org-contrib/babel/examples/o18.org (Tom Dye's article on
> Archaelogy in Oceania), I ran into #+srcname vs #+name problems: when
> Eric's changes do go into org and the new org is used to publish Worg,
> there is going to be some breakage. Actually, o18.org is the extent of
> breakage that I saw, so it doesn't look too bad.
>
> But I also ran into a second (unrelated) issue. Here's a minimal example:
>
> * Conclusion
>
> #+begin_src latex 
>
> #+end_src
>
> Exporting to html gives me the attached backtrace. But the underlying reason
> is easy to demonstrate: if you C-c C-c on the empty source block, you get:
>
> ,
> | * Conclusion
> | 
> | #+begin_src latex 
> | 
> | #+end_src
> | 
> | #+results:
> | #+END_LaTeX
> | #+BEGIN_LaTeX
> `
>
> Nick
>
> Versions:
> Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
> GNU Emacs 24.0.90.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.0) of 
> 2011-10-27
>
>
>

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

[O] Evaluation on export has stopped working, org-export-blocks hook was culprit?

[Herbert Sitz]

I had a system that was working fine, but it seems to have stopped processing
babel source blocks on export.  I've switched between Org 7.4 and 7.7 on Win32
Emacs 23.1 and both have the problem.  

As I was writing this up I discovered that the problem was caused by a line I
had added to my .emacs.  This line was preventing any evaluation of source
blocks at all:

 '(org-export-blocks (quote ((comment org-export-blocks-format-comment nil)
(ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot
nil


I had innocently been testing out export of comments with org-export-blocks hook
and I had forgotten I put that in .emacs some days ago.  

It seems to have prevented any processing of my source blocks on export.  That
is the export of the block simply exports the code between begin_src and
end_src, regardless of the value of :exports option (both, none, results, code).
 And, of course, the code in the source block was not getting evaluated.

Don't know if this is a known problem or not.  

Thanks,

Herb

Re: [O] emacs 24.1 and org compatibility

[Michael Bach]

Tassilo Horn  writes:

> Michael Bach  writes:
>
>> [nothing]
>
> I agree with all that you've said. :-)
>

Hm.  Since my subject line is the only thing I said, that was easy.  :-)

So for the actual issue: After pulling emacs from bzr and org mode from
git today, org-capture failed with error:

void-function: org-pop-to-buffer-same-window

After digging around, I found the definition in org-compat.el from the
git repo and a comment within saying that "`pop-to-buffer-same-window'
has been introduced with Emacs 24.1".

I now require the org-compat from git repo instead of the one built into
org-mode from emacs 24.0.90.1 since org-pop-to-buffer-same-window is not
defined within that.

I am not fully used to development versions yet...

Sorry for sending only an empty draft and then some noise.

cheers 

Re: [O] Problem after updating org: C-c a a broken

[Sebastien Vauban]

Hi Nick and Markus,

Nick Dokos wrote:
> Nick Dokos  wrote:
>> Markus Heller  wrote:
>> 
>> > Hm, so ok, restarting emacs actually solved it.
>> > 
>> > Kinda weird, because I never had to do this when updating org (I don't
>> > compile the sources, I just do C-c C-x !).
>> > 
>> > Seems a bit odd to me but it's working again so I'm happy :)
>> > 
>> > I apologize for the noise.
>> 
>> Did you try M-x org-reload RET? That should work but sometimes it misses
>> something (but if it does, that would be a bug of course, so report it).
>
> nm - I missed the C-c C-x !

I don't think org-reload is fully bullet-proof. I think it misses changes in
defvars, deffaces, and the like: once set, if the default is changed, it's not
updated by reloading the files.

Now, in 99.999% of the cases, that should not be a problem. But to be really
safe...

Last thing, how is this problem solved by a restart of Emacs and not by a
reload, not sure we can easily understand.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Problem after updating org: C-c a a broken

[Nick Dokos]

Nick Dokos  wrote:

> Markus Heller  wrote:
> 
> 
> > Hm, so ok, restarting emacs actually solved it.
> > 
> > Kinda weird, because I never had to do this when updating org (I don't
> > compile the sources, I just do C-c C-x !).
> > 
> > Seems a bit odd to me but it's working again so I'm happy :)
> > 
> > I apologize for the noise.
> > 
> > 
> 
> Did you try M-x org-reload RET? That should work but sometimes it misses
> something (but if it does, that would be a bug of course, so report it).
> 
> 

nm - I missed the C-c C-x !

Re: [O] Problem after updating org: C-c a a broken

[Nick Dokos]

Markus Heller  wrote:


> Hm, so ok, restarting emacs actually solved it.
> 
> Kinda weird, because I never had to do this when updating org (I don't
> compile the sources, I just do C-c C-x !).
> 
> Seems a bit odd to me but it's working again so I'm happy :)
> 
> I apologize for the noise.
> 
> 

Did you try M-x org-reload RET? That should work but sometimes it misses
something (but if it does, that would be a bug of course, so report it).

Re: [O] Problem after updating org: C-c a a broken

[Markus Heller]

Markus Heller  writes:

> Nick Dokos  writes:
>
>> Markus Heller  wrote:
>>
>>> Hello all,
>>> 
>>> just pulled from git.
>>> 
>>> When I type C-c a a to pull up the agenda, I get the error shown below.
>>> 
>>> This used to work prior to the update.
>>> 
>>> Org version is 7.7, pulled 5 min ago on emacs 23.3.1.
>>> 
>>> Help please, can't access my agenda anymore :(
>>> 
>>> Thanks
>>> Markus
>>> 
>>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>>   format(nil "COMMENT")
>>>   (setq re (format org-heading-keyword-regexp-format org-comment-string))
>>
>> I can't reproduce this: Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
>> (this is a pull from about 30mins ago plus Eric Schulte's code block 
>> keywords patch).
>>
>> org-heading-keyword-regexp-format is initialized to nil and made
>> buffer-local in org.el It is set to a non-nil value in
>> org-set-regexps-and-options which is called from org-mode.  So if the
>> visited files's major mode is indeed org, I cannot imagine how this
>> error can come about.
>>
>> What happens if you visit the three files in your agenda list and *then*
>> do C-c a a?  While visiting each file, do C-h v
>> org-heading-keyword-regexp-format RET and see if it is nil or not.
>>
>
> Hi Nick,
>
> I've visited all 3 agenda files.  C-c a a doesn't work in any of them,
> and org-heading-keyword-regexp-format is NIL in all 3 of them.
>
> Other thoughts?
>
> Markus

Hm, so ok, restarting emacs actually solved it.

Kinda weird, because I never had to do this when updating org (I don't
compile the sources, I just do C-c C-x !).

Seems a bit odd to me but it's working again so I'm happy :)

I apologize for the noise.

Re: [O] Problem after updating org: C-c a a broken

[Nick Dokos]

Markus Heller  wrote:

> Nick Dokos  writes:
> 
> > Markus Heller  wrote:
> >
> >> Hello all,
> >> 
> >> just pulled from git.
> >> 
> >> When I type C-c a a to pull up the agenda, I get the error shown below.
> >> 
> >> This used to work prior to the update.
> >> 
> >> Org version is 7.7, pulled 5 min ago on emacs 23.3.1.
> >> 
> >> Help please, can't access my agenda anymore :(
> >> 
> >> Thanks
> >> Markus
> >> 
> >> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> >>   format(nil "COMMENT")
> >>   (setq re (format org-heading-keyword-regexp-format org-comment-string))
> >
> > I can't reproduce this: Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
> > (this is a pull from about 30mins ago plus Eric Schulte's code block 
> > keywords patch).
> >
> > org-heading-keyword-regexp-format is initialized to nil and made
> > buffer-local in org.el It is set to a non-nil value in
> > org-set-regexps-and-options which is called from org-mode.  So if the
> > visited files's major mode is indeed org, I cannot imagine how this
> > error can come about.
> >
> > What happens if you visit the three files in your agenda list and *then*
> > do C-c a a?  While visiting each file, do C-h v
> > org-heading-keyword-regexp-format RET and see if it is nil or not.
> >
> 
> Hi Nick,
> 
> I've visited all 3 agenda files.  C-c a a doesn't work in any of them,
> and org-heading-keyword-regexp-format is NIL in all 3 of them.
> 
> Other thoughts?
> 

Do C-h v major-mode RET  when you are visiting one of those files. What do you 
get?

Re: [O] Problem after updating org: C-c a a broken

[Markus Heller]

Nick Dokos  writes:

> Markus Heller  wrote:
>
>> Hello all,
>> 
>> just pulled from git.
>> 
>> When I type C-c a a to pull up the agenda, I get the error shown below.
>> 
>> This used to work prior to the update.
>> 
>> Org version is 7.7, pulled 5 min ago on emacs 23.3.1.
>> 
>> Help please, can't access my agenda anymore :(
>> 
>> Thanks
>> Markus
>> 
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   format(nil "COMMENT")
>>   (setq re (format org-heading-keyword-regexp-format org-comment-string))
>
> I can't reproduce this: Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
> (this is a pull from about 30mins ago plus Eric Schulte's code block keywords 
> patch).
>
> org-heading-keyword-regexp-format is initialized to nil and made
> buffer-local in org.el It is set to a non-nil value in
> org-set-regexps-and-options which is called from org-mode.  So if the
> visited files's major mode is indeed org, I cannot imagine how this
> error can come about.
>
> What happens if you visit the three files in your agenda list and *then*
> do C-c a a?  While visiting each file, do C-h v
> org-heading-keyword-regexp-format RET and see if it is nil or not.
>

Hi Nick,

I've visited all 3 agenda files.  C-c a a doesn't work in any of them,
and org-heading-keyword-regexp-format is NIL in all 3 of them.

Other thoughts?

Markus

Re: [O] Problem after updating org: C-c a a broken

[Nick Dokos]

Markus Heller  wrote:

> Hello all,
> 
> just pulled from git.
> 
> When I type C-c a a to pull up the agenda, I get the error shown below.
> 
> This used to work prior to the update.
> 
> Org version is 7.7, pulled 5 min ago on emacs 23.3.1.
> 
> Help please, can't access my agenda anymore :(
> 
> Thanks
> Markus
> 
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   format(nil "COMMENT")
>   (setq re (format org-heading-keyword-regexp-format org-comment-string))

I can't reproduce this: Org-mode version 7.7 (release_7.7.485.gcfed6.dirty)
(this is a pull from about 30mins ago plus Eric Schulte's code block keywords 
patch).

org-heading-keyword-regexp-format is initialized to nil and made
buffer-local in org.el It is set to a non-nil value in
org-set-regexps-and-options which is called from org-mode.  So if the
visited files's major mode is indeed org, I cannot imagine how this
error can come about.

What happens if you visit the three files in your agenda list and *then*
do C-c a a?  While visiting each file, do C-h v
org-heading-keyword-regexp-format RET and see if it is nil or not.

Nick

>   (save-excursion (remove-text-properties (point-min) (point-max) pall) (when 
> org-agenda-skip-archived-trees (goto-char ...) (while ... ...)) (goto-char 
> (point-min)) (setq re (format org-heading-keyword-regexp-format 
> org-comment-string)) (while (re-search-forward re nil t) (add-text-properties 
> ... ... pc)))
>   (catch (quote nextfile) (if (bufferp file) (set-buffer file) 
> (org-check-agenda-file file) (set-buffer ...)) (widen) (setq bmp 
> (buffer-modified-p)) (org-refresh-category-properties) (setq 
> org-todo-keywords-for-agenda (append org-todo-keywords-for-agenda 
> org-todo-keywords-1)) (setq org-done-keywords-for-agenda (append 
> org-done-keywords-for-agenda org-done-keywords)) (setq 
> org-todo-keyword-alist-for-agenda (append org-todo-keyword-alist-for-agenda 
> org-todo-key-alist)) (setq org-drawers-for-agenda (append 
> org-drawers-for-agenda org-drawers)) (setq org-tag-alist-for-agenda (append 
> org-tag-alist-for-agenda org-tag-alist)) (save-excursion 
> (remove-text-properties ... ... pall) (when org-agenda-skip-archived-trees 
> ... ...) (goto-char ...) (setq re ...) (while ... ...)) 
> (set-buffer-modified-p bmp))
>   (while (setq file (pop files)) (catch (quote nextfile) (if ... ... ... ...) 
> (widen) (setq bmp ...) (org-refresh-category-properties) (setq 
> org-todo-keywords-for-agenda ...) (setq org-done-keywords-for-agenda ...) 
> (setq org-todo-keyword-alist-for-agenda ...) (setq org-drawers-for-agenda 
> ...) (setq org-tag-alist-for-agenda ...) (save-excursion ... ... ... ... ...) 
> (set-buffer-modified-p bmp)))
>   (save-restriction (while (setq file ...) (catch ... ... ... ... ... ... ... 
> ... ... ... ... ...)))
>   (save-excursion (save-restriction (while ... ...)))
>   (let ((pa ...) (pc ...) (pall ...) (inhibit-read-only t) (rea ...) bmp file 
> re) (save-excursion (save-restriction ...)) (setq 
> org-todo-keywords-for-agenda (org-uniquify org-todo-keywords-for-agenda)) 
> (setq org-todo-keyword-alist-for-agenda (org-uniquify 
> org-todo-keyword-alist-for-agenda) org-tag-alist-for-agenda (org-uniquify 
> org-tag-alist-for-agenda)))
>   org-prepare-agenda-buffers(("h:/org/NMR.org" "h:/org/Office.org" 
> "h:/org/refile.org"))
>   (if org-agenda-multi (progn (setq buffer-read-only nil) (goto-char ...) 
> (unless ... ...) (narrow-to-region ... ...)) (org-agenda-reset-markers) (setq 
> org-agenda-contributing-files nil) (setq org-agenda-columns-active nil) 
> (org-prepare-agenda-buffers (org-agenda-files nil ...)) (setq 
> org-todo-keywords-for-agenda (org-uniquify org-todo-keywords-for-agenda)) 
> (setq org-done-keywords-for-agenda (org-uniquify 
> org-done-keywords-for-agenda)) (setq org-drawers-for-agenda (org-uniquify 
> org-drawers-for-agenda)) (let* (... ...) (cond ... ... ... ... ... ... ...) 
> (unless ... ...)) (setq buffer-read-only nil) (let (...) (erase-buffer)) 
> (org-agenda-mode) (and name (not org-agenda-name) (org-set-local ... name)))
>   org-prepare-agenda("Day/Week")
>   (let* ((span ...) (today ...) (sd ...) (ndays ...) 
> (org-agenda-start-on-weekday ...) (thefiles ...) (files thefiles) (start ...) 
> (day-numbers ...) (day-cnt 0) (inhibit-redisplay ...) s e rtn rtnall file 
> date d start-pos end-pos todayp clocktable-start clocktable-end filter) (setq 
> org-agenda-redo-command (list ... ... start-day ...)) (dotimes (n ...) (push 
> ... day-numbers)) (setq day-numbers (nreverse day-numbers)) (setq 
> clocktable-start (car day-numbers) clocktable-end (1+ ...)) 
> (org-prepare-agenda "Day/Week") (org-set-local (quote org-starting-day) (car 
> day-numbers)) (org-set-local (quote org-arg-loc) arg) (org-set-local (quote 
> org-agenda-current-span) (org-agenda-ndays-to-span span)) (unless 
> org-agenda-compact-blocks (let* ... ... ...) (add-text-properties s ... ...) 
> (org-agenda-mark-header-line s)) (while (setq d ...) (setq date ... s ...

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

Nick Dokos  writes:

> Eric Schulte  wrote:
>
>> The attached updated patch fixes a bug in the original.
>> 
>
> Minor problem in applying:
>
> ,
> | $ git apply ~/Mail/inbox/724
> | /home/nick/Mail/inbox/724:671: trailing whitespace.
> | #+name: 
> | /home/nick/Mail/inbox/724:599: new blank line at EOF.
> | +
> | warning: 2 lines add whitespace errors.
> `

The attached version fixes these issues, Thanks -- Eric

>From 0e43d59ee8d46a63f86780a502de726271bc39de Mon Sep 17 00:00:00 2001
From: Eric Schulte 
Date: Fri, 28 Oct 2011 10:44:21 -0600
Subject: [PATCH] removing code block, results and call-line synonyms -- BREAKING CHANGE

Following a round of on-list discussion many code block synonyms have
been removed, moving forward the following syntax is valid.

- call lines are specified with #+call:
- code blocks are named with #+name:
- results are named with #+name:, however results generated by a code
  block may still be labeled with #+results:, and tables named with
  #+tblname: will be considered to be named results

The following function may be used to update an existing Org-mode
buffer to the new syntax.

  (defun update-org-buffer ()
"Update an Org-mode buffer to the new data, code block and call line syntax."
(interactive)
(save-excursion
  (flet ((to-re (lst) (concat "^[ \t]*#\\+" (regexp-opt lst t)
  "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*"))
 (update (re new)
 (goto-char (point-min))
 (while (re-search-forward re nil t)
   (replace-match new nil nil nil 1
(let ((old-re (to-re '("RESULTS" "DATA" "SRCNAME" "SOURCE")))
  (lob-re (to-re '("LOB")))
  (case-fold-search t))
  (update old-re "name")
  (update lob-re "call")

Note: If an old version of Org-mode (e.g., the one shipped with Emacs)
  is installed on your system many of the important variables will
  be pre-defined with a defvar and *will not* have their values
  automatically updated, these include the following.
  - org-babel-data-names
  - org-babel-result-regexp
  - org-babel-src-block-regexp
  - org-babel-src-name-regexp
  - org-babel-src-name-w-name-regexp
  It may be necessary to either remove the source code of older
  versions of Org-mode, or to explicitly evaluate the ob.el file.

* lisp/ob-exp.el (org-exp-res/src-name-cleanup): Updated
  Documentation.
* lisp/ob-lob.el (org-babel-block-lob-one-liner-regexp): Updated
  regular expression.
  (org-babel-inline-lob-one-liner-regexp): Updated regular expression.
* lisp/ob-ref.el (org-babel-ref-resolve): Notice when something that
  looks like a data results may actually be a code block.
* lisp/ob-table.el: Updated documentation.
* lisp/ob.el (org-babel-src-name-regexp): Simplified regexp.
  (org-babel-get-src-block-info): Updated match strings.
  (org-babel-data-names): Simplified acceptable names.
  (org-babel-find-named-block): Indentation.
  (org-babel-find-named-result): Updated to not return a code block as
  a result.
* lisp/org.el (org-fontify-meta-lines-and-blocks-1): Removing
  references to old syntactic elements.
  (org-additional-option-like-keywords): Removing references to old
  syntactic elements.
* contrib/babel/library-of-babel.org: Updated to make use of the new
  syntax.
* testing/examples/babel-dangerous.org: Updated to make use of the new
  syntax.
* testing/examples/babel.org: Updated to make use of the new syntax.
* testing/examples/ob-awk-test.org: Updated to make use of the new
  syntax.
* testing/examples/ob-fortran-test.org: Updated to make use of the new
  syntax.
* testing/lisp/test-ob.el: Removed two bad tests which tested the
  literal values of old regular expressions rather than their
  behavior.
---
 contrib/babel/library-of-babel.org   |   48 +-
 lisp/ob-exp.el   |2 +-
 lisp/ob-lob.el   |   13 +
 lisp/ob-ref.el   |5 +++
 lisp/ob-table.el |2 +-
 lisp/ob.el   |   31 -
 lisp/org.el  |9 ++
 testing/examples/babel-dangerous.org |5 +++-
 testing/examples/babel.org   |   30 ++--
 testing/examples/ob-awk-test.org |4 +-
 testing/examples/ob-fortran-test.org |4 +-
 testing/lisp/test-ob.el  |   42 -
 12 files changed, 77 insertions(+), 118 deletions(-)

diff --git a/contrib/babel/library-of-babel.org b/contrib/babel/library-of-babel.org
index 2db9d4c..571eb70 100644
--- a/contrib/babel/library-of-babel.org
+++ b/contrib/babel/library-of-babel.org
@@ -22,7 +22,7 @@
 
 A collection of simple utility functions:
 
-#+srcname: echo
+#+name: echo
 #+begin_src emacs-lisp :var input="echo'd"
   input
 #+end_src
@@ -35,7 +35,7 @@ Read the contents of the file at =fil

Re: [O] [RFC] Standardized code block keywords

[Nick Dokos]

Eric Schulte  wrote:

> The attached updated patch fixes a bug in the original.
> 

Minor problem in applying:

,
| $ git apply ~/Mail/inbox/724
| /home/nick/Mail/inbox/724:671: trailing whitespace.
| #+name: 
| /home/nick/Mail/inbox/724:599: new blank line at EOF.
| +
| warning: 2 lines add whitespace errors.
`

[O] Problem after updating org: C-c a a broken

[Markus Heller]

Hello all,

just pulled from git.

When I type C-c a a to pull up the agenda, I get the error shown below.

This used to work prior to the update.

Org version is 7.7, pulled 5 min ago on emacs 23.3.1.

Help please, can't access my agenda anymore :(

Thanks
Markus

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  format(nil "COMMENT")
  (setq re (format org-heading-keyword-regexp-format org-comment-string))
  (save-excursion (remove-text-properties (point-min) (point-max) pall) (when 
org-agenda-skip-archived-trees (goto-char ...) (while ... ...)) (goto-char 
(point-min)) (setq re (format org-heading-keyword-regexp-format 
org-comment-string)) (while (re-search-forward re nil t) (add-text-properties 
... ... pc)))
  (catch (quote nextfile) (if (bufferp file) (set-buffer file) 
(org-check-agenda-file file) (set-buffer ...)) (widen) (setq bmp 
(buffer-modified-p)) (org-refresh-category-properties) (setq 
org-todo-keywords-for-agenda (append org-todo-keywords-for-agenda 
org-todo-keywords-1)) (setq org-done-keywords-for-agenda (append 
org-done-keywords-for-agenda org-done-keywords)) (setq 
org-todo-keyword-alist-for-agenda (append org-todo-keyword-alist-for-agenda 
org-todo-key-alist)) (setq org-drawers-for-agenda (append 
org-drawers-for-agenda org-drawers)) (setq org-tag-alist-for-agenda (append 
org-tag-alist-for-agenda org-tag-alist)) (save-excursion 
(remove-text-properties ... ... pall) (when org-agenda-skip-archived-trees ... 
...) (goto-char ...) (setq re ...) (while ... ...)) (set-buffer-modified-p bmp))
  (while (setq file (pop files)) (catch (quote nextfile) (if ... ... ... ...) 
(widen) (setq bmp ...) (org-refresh-category-properties) (setq 
org-todo-keywords-for-agenda ...) (setq org-done-keywords-for-agenda ...) (setq 
org-todo-keyword-alist-for-agenda ...) (setq org-drawers-for-agenda ...) (setq 
org-tag-alist-for-agenda ...) (save-excursion ... ... ... ... ...) 
(set-buffer-modified-p bmp)))
  (save-restriction (while (setq file ...) (catch ... ... ... ... ... ... ... 
... ... ... ... ...)))
  (save-excursion (save-restriction (while ... ...)))
  (let ((pa ...) (pc ...) (pall ...) (inhibit-read-only t) (rea ...) bmp file 
re) (save-excursion (save-restriction ...)) (setq org-todo-keywords-for-agenda 
(org-uniquify org-todo-keywords-for-agenda)) (setq 
org-todo-keyword-alist-for-agenda (org-uniquify 
org-todo-keyword-alist-for-agenda) org-tag-alist-for-agenda (org-uniquify 
org-tag-alist-for-agenda)))
  org-prepare-agenda-buffers(("h:/org/NMR.org" "h:/org/Office.org" 
"h:/org/refile.org"))
  (if org-agenda-multi (progn (setq buffer-read-only nil) (goto-char ...) 
(unless ... ...) (narrow-to-region ... ...)) (org-agenda-reset-markers) (setq 
org-agenda-contributing-files nil) (setq org-agenda-columns-active nil) 
(org-prepare-agenda-buffers (org-agenda-files nil ...)) (setq 
org-todo-keywords-for-agenda (org-uniquify org-todo-keywords-for-agenda)) (setq 
org-done-keywords-for-agenda (org-uniquify org-done-keywords-for-agenda)) (setq 
org-drawers-for-agenda (org-uniquify org-drawers-for-agenda)) (let* (... ...) 
(cond ... ... ... ... ... ... ...) (unless ... ...)) (setq buffer-read-only 
nil) (let (...) (erase-buffer)) (org-agenda-mode) (and name (not 
org-agenda-name) (org-set-local ... name)))
  org-prepare-agenda("Day/Week")
  (let* ((span ...) (today ...) (sd ...) (ndays ...) 
(org-agenda-start-on-weekday ...) (thefiles ...) (files thefiles) (start ...) 
(day-numbers ...) (day-cnt 0) (inhibit-redisplay ...) s e rtn rtnall file date 
d start-pos end-pos todayp clocktable-start clocktable-end filter) (setq 
org-agenda-redo-command (list ... ... start-day ...)) (dotimes (n ...) (push 
... day-numbers)) (setq day-numbers (nreverse day-numbers)) (setq 
clocktable-start (car day-numbers) clocktable-end (1+ ...)) (org-prepare-agenda 
"Day/Week") (org-set-local (quote org-starting-day) (car day-numbers)) 
(org-set-local (quote org-arg-loc) arg) (org-set-local (quote 
org-agenda-current-span) (org-agenda-ndays-to-span span)) (unless 
org-agenda-compact-blocks (let* ... ... ...) (add-text-properties s ... ...) 
(org-agenda-mark-header-line s)) (while (setq d ...) (setq date ... s ...) (if 
... ... ...) (setq files thefiles rtnall nil) (while ... ...) (if 
org-agenda-include-diary ...) (if ... ...)) (when (and 
org-agenda-clockreport-mode clocktable-start) (let ... ... ... ... ... ... ... 
...)) (goto-char (point-min)) (or org-agenda-multi (org-fit-agenda-window)) 
(unless (and ... ...) (goto-char ...) (recenter -1) (if ... ...)) (goto-char 
(or start-pos 1)) (add-text-properties (point-min) (point-max) (quote ...)) (if 
(eq org-agenda-show-log ...) (org-agenda-show-clocking-issues)) 
(org-finalize-agenda) (setq buffer-read-only t) (message ""))
  org-agenda-list(nil)
  call-interactively(org-agenda-list)
  (cond ((setq entry ...) (if ... ... ...)) ((equal keys "C") (setq 
org-agenda-custom-commands org-agenda-custom-commands-orig) (customize-variable 
...)) ((equal keys "a") (call-int

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

The attached updated patch fixes a bug in the original.

>From 0e43d59ee8d46a63f86780a502de726271bc39de Mon Sep 17 00:00:00 2001
From: Eric Schulte 
Date: Fri, 28 Oct 2011 10:44:21 -0600
Subject: [PATCH] removing code block, results and call-line synonyms -- BREAKING CHANGE

Following a round of on-list discussion many code block synonyms have
been removed, moving forward the following syntax is valid.

- call lines are specified with #+call:
- code blocks are named with #+name:
- results are named with #+name:, however results generated by a code
  block may still be labeled with #+results:, and tables named with
  #+tblname: will be considered to be named results

The following function may be used to update an existing Org-mode
buffer to the new syntax.

  (defun update-org-buffer ()
"Update an Org-mode buffer to the new data, code block and call line syntax."
(interactive)
(save-excursion
  (flet ((to-re (lst) (concat "^[ \t]*#\\+" (regexp-opt lst t)
  "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*"))
 (update (re new)
 (goto-char (point-min))
 (while (re-search-forward re nil t)
   (replace-match new nil nil nil 1
(let ((old-re (to-re '("RESULTS" "DATA" "SRCNAME" "SOURCE")))
  (lob-re (to-re '("LOB")))
  (case-fold-search t))
  (update old-re "name")
  (update lob-re "call")

Note: If an old version of Org-mode (e.g., the one shipped with Emacs)
  is installed on your system many of the important variables will
  be pre-defined with a defvar and *will not* have their values
  automatically updated, these include the following.
  - org-babel-data-names
  - org-babel-result-regexp
  - org-babel-src-block-regexp
  - org-babel-src-name-regexp
  - org-babel-src-name-w-name-regexp
  It may be necessary to either remove the source code of older
  versions of Org-mode, or to explicitly evaluate the ob.el file.

* lisp/ob-exp.el (org-exp-res/src-name-cleanup): Updated
  Documentation.
* lisp/ob-lob.el (org-babel-block-lob-one-liner-regexp): Updated
  regular expression.
  (org-babel-inline-lob-one-liner-regexp): Updated regular expression.
* lisp/ob-ref.el (org-babel-ref-resolve): Notice when something that
  looks like a data results may actually be a code block.
* lisp/ob-table.el: Updated documentation.
* lisp/ob.el (org-babel-src-name-regexp): Simplified regexp.
  (org-babel-get-src-block-info): Updated match strings.
  (org-babel-data-names): Simplified acceptable names.
  (org-babel-find-named-block): Indentation.
  (org-babel-find-named-result): Updated to not return a code block as
  a result.
* lisp/org.el (org-fontify-meta-lines-and-blocks-1): Removing
  references to old syntactic elements.
  (org-additional-option-like-keywords): Removing references to old
  syntactic elements.
* contrib/babel/library-of-babel.org: Updated to make use of the new
  syntax.
* testing/examples/babel-dangerous.org: Updated to make use of the new
  syntax.
* testing/examples/babel.org: Updated to make use of the new syntax.
* testing/examples/ob-awk-test.org: Updated to make use of the new
  syntax.
* testing/examples/ob-fortran-test.org: Updated to make use of the new
  syntax.
* testing/lisp/test-ob.el: Removed two bad tests which tested the
  literal values of old regular expressions rather than their
  behavior.
---
 contrib/babel/library-of-babel.org   |   48 +-
 lisp/ob-exp.el   |2 +-
 lisp/ob-lob.el   |   13 +
 lisp/ob-ref.el   |5 +++
 lisp/ob-table.el |2 +-
 lisp/ob.el   |   31 -
 lisp/org.el  |9 ++
 testing/examples/babel-dangerous.org |5 +++-
 testing/examples/babel.org   |   30 ++--
 testing/examples/ob-awk-test.org |4 +-
 testing/examples/ob-fortran-test.org |4 +-
 testing/lisp/test-ob.el  |   42 -
 12 files changed, 77 insertions(+), 118 deletions(-)

diff --git a/contrib/babel/library-of-babel.org b/contrib/babel/library-of-babel.org
index 2db9d4c..571eb70 100644
--- a/contrib/babel/library-of-babel.org
+++ b/contrib/babel/library-of-babel.org
@@ -22,7 +22,7 @@
 
 A collection of simple utility functions:
 
-#+srcname: echo
+#+name: echo
 #+begin_src emacs-lisp :var input="echo'd"
   input
 #+end_src
@@ -35,7 +35,7 @@ Read the contents of the file at =file=.  The =:results vector= and
 =:results scalar= header arguments can be used to read the contents of
 file as either a table or a string.
 
-#+srcname: read
+#+name: read
 #+begin_src emacs-lisp :var file="" :var format=""
   (if (string= format "csv")
   (with-temp-buffer
@@ -49,7 +49,7 @@ file as either a table or a string.
 Write =data= to a file at =file=. 

[O] emacs 24.1 and org compatibility

[Michael Bach]

Re: [O] Elisp programming style

[Tom Prince]

Perhaps 

,---
| (defun main-function (args)   
| (let ((var (assoc :key1 args)))  ; extracting var once
| ...   
| (helper-function1 ... var ...) ; inside let using var 
| (helper-function2 ... var ...) ; inside let using var 
| ))
|   
| (defun helper-function1 (var')
| ...   
| ) 
|   
| (defun helper-function2 (var')
| ...   
| ) 
`---

or

,-
| (defun get-key1 (args) (assoc :key1 args))  
| (defun main-function (args) 
| (let ((value (get-key1 args))   ; extracting var 1st time   
| ... 
| )   
| (helper-function1 ...) ; outside let
| (helper-function2 ...) ; outside let
| )   
| 
| (defun helper-function1 (args)  
| (let ((value (get-key1 args))   ; extracting var 2nd time   
| ... 
| ))  
| 
| (defun helper-function2 (args)  
| (let ((value (get-key1 args))   ; extracting var 3rd time   
| ... 
| ))  
`-


I likely wouldn't suggest the second, unless get-key1 was actually
something more complicated than your example.

  Tom

[O] Patch to customize output of tables in LaTeX exporter.

[Niels Giesen]

Dear list,

Attached is a patch that allows some customization of tables in LaTeX
export.

It adds three new customizable with default values:

  org-export-latex-tables-tstart : nil
  org-export-latex-tables-hline  : "\\hline"
  org-export-latex-tables-tend   : nil

These variables allows users to use e.g. the booktabs package (use
\\toprule, \\midrule and \\bottomrule for the respective variables above
- these are options you'll find in the defcustoms too) and create more
beautiful tables in LaTeX documents.

The patch also fixes the double rule after the table head when using a
longtable environment, as this 1) is ugly and 2) caused booktabs
longtables to go quite awry.

The patch does - save for the longtable fix - bring no change to the
export of existing code as long as the defaults are not changed.

>From f2d9cf34b1b95c7e6941c8f9129ae9e32ba33444 Mon Sep 17 00:00:00 2001
From: Niels Giesen 
Date: Thu, 27 Oct 2011 09:23:16 +0200
Subject: [PATCH] Add defcustoms for LaTeX export of table rules :tstart, :hline and :tend
 Fix double rule in longtable.

This allows users to use e.g. the booktabs package and create more
beautiful tables in LaTeX documents. Also fix double headline rules
when using a longtable environment, as this caused booktabs longtables
to go quite awry.

* lisp/org-latex.el:
New defcustoms and default values:

  org-export-latex-tables-tstart : nil
  org-export-latex-tables-hline  : "\\hline"
  org-export-latex-tables-tend   : nil

* lisp/org-table.el (orgtbl-to-generic): add check for :skipheadrule.
When present, the :hline following the head will be skipped. This is
necessary to avoid doubling of horizontal rules in LaTeX longtable
environments and consequent width problems.
---
 lisp/org-latex.el |   38 ++
 lisp/org-table.el |3 ++-
 2 files changed, 36 insertions(+), 5 deletions(-)

diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 649e4a7..3e47359 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -369,6 +369,30 @@ When nil, grouping causes only separation lines between groups."
   :group 'org-export-latex
   :type 'boolean)
 
+(defcustom org-export-latex-tables-tstart nil
+  "LaTeX command for top rule for tables."
+  :group 'org-export-latex
+  :type '(choice
+  (const :tag "Nothing" nil)
+  (string :tag "String")
+  (const  :tag "Booktabs default: \\toprule" "\\toprule")))
+
+(defcustom org-export-latex-tables-hline "\\hline"
+  "LaTeX command to use for a rule somewhere in the middle of a table."
+  :group 'org-export-latex
+  :type '(choice
+  (string :tag "String")
+  (const  :tag "Standard: \\hline" "\\hline")
+  (const  :tag "Booktabs default: \\midrule" "\\midrule")))
+
+(defcustom org-export-latex-tables-tend nil
+  "LaTeX command for bottom rule for tables."
+  :group 'org-export-latex
+  :type '(choice
+  (const :tag "Nothing" nil)
+  (string :tag "String")
+  (const  :tag "Booktabs default: \\bottomrule" "\\bottomrule")))
+
 (defcustom org-export-latex-low-levels 'itemize
   "How to convert sections below the current level of sectioning.
 This is specified by the `org-export-headline-levels' option or the
@@ -1998,14 +2022,20 @@ The conversion is made depending of STRING-BEFORE and STRING-AFTER."
 align))
 (orgtbl-to-latex
  lines
- `(:tstart nil :tend nil
+ `(:tstart ,org-export-latex-tables-tstart
+   :tend ,org-export-latex-tables-tend
+   :hline ,org-export-latex-tables-hline
+   :skipheadrule ,longtblp
:hlend ,(if longtblp
(format "
-\\hline
+%s
 \\endhead
-\\hline\\multicolumn{%d}{r}{Continued on next page}\\
+%s\\multicolumn{%d}{r}{Continued on next page}\\
 \\endfoot
-\\endlastfoot" (length org-table-last-alignment))
+\\endlastfoot"
+   org-export-latex-tables-hline
+   org-export-latex-tables-hline
+   (length org-table-last-alignment))
  nil)))
 (if (not longtblp) (format "\n\\end{%s}" tabular-env))
 (if longtblp "\n" (if org-export-latex-tables-centered
diff --git a/lisp/org-table.el b/lisp/org-table.el
index edcdbe1..247f585 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -4460,6 +4460,7 @@ directly by `orgtbl-send-table'.  See manual."
 
   (let* ((splicep (plist-get params :splice))
 	 (hline (plist-get params :hline))
+ (skipheadrule (plist-get params :skipheadrule))
 	 (remove-nil-linesp (plist-get params :remove-nil-lines))
 	 (remove-newlines (plist-get params :remove-newlines))
 	 (*orgtbl-hline* hline)
@@ -4505,7 +4506,7 @@ directly by `orgtbl-send-table'.  See manual."
 		 (*o

Re: [O] [PATCH] Adding features to contrib/lisp/org-collector.el (propview)

[Eric Schulte]

Bastien  writes:

> Jonathan BISSON  writes:
>
>> Here it is,
>
> Thanks for the quick reply -- since Eric also replied, I let 
> him decide about this!
>

[Eric] touches his nose only to realize it is already too late...

Hi Jonathan,

Sorry to ask for yet another re-submission, but would you mind
regenerating this patch using git diff, i.e.,

  cd org-mode/
  git diff > new-patch.patch

or even better you could commit your changes with git, and then generate
the patch using the git format-patch utility, with something like

  cd org-mode/
  git add contrib/lisp/org-collector.el
  git commit -m "your commit message"
  git format-patch -o /tmp/ HEAD~1

and then attaching the resulting patch file in your /tmp/ directory.
The reason I ask is that I'm unable to apply your current patch with
either the `git' or `patch' commands.

Thanks! -- Eric

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

Re: [O] OT: collage of scripts [was: Re: table alignment failed for Asian char

[brian powell]

* One of my favorite Hofstadter books is: "Le Ton beau de Marot: In
Praise of the Music of Language (ISBN 0-465-08645-4), published by
Basic Books in 1997, is a book by Douglas Hofstadter in which he
explores the meaning, strengths, failings, and beauty of translation."

** "Translation between frames of reference — languages, cultures,
modes of expression, or indeed between one person's thoughts and
another — becomes an element in many of the same concepts Hofstadter
has addressed in prior works, such as reference and self-reference,
structure and function, and artificial intelligence."

** This topic correctly has been labeled "OT"; but, on the subject of
translation and "modes of expression" (in the OrgMode table); this is
related to the original thread/topic: "table alignment failed for
Asian chars."--getting back there for a moment:

*** Are there any Asian/Chinese/Tamil character sets that have fixed
widths?  Chinese writing is "picture writing", where characters
actually represent, to varying degrees, a picture or an abstract
concept of the thing they represent.

 I remember many years ago, suggesting to fellow software
engineers, that they do just that: Make fixed-width Tamil character
sets that will work well in EMACS.

* One possibly simple "work-around" (not sure this is what you seek):
Put all your non-fixed width Asian characters into cells like:
"[[blahAsianCharactersOrPNGofAsianChars][A]]"

** All you'd see is an "A" and then the table will look "covered down"
(in an OrgMode buffer)--but you may have to manually adjust the
OrgMode table.

*** Another idea: you just put something like A555 (simple
PlainText--maybe the unicode string equivalent like: "U+024B62") in
the table and have a program that replace the PlainText  U+024B62 with
the AsianChars and/or a .PNG picture file link when you click an
icon/run the program.  There are ELISP programs which help with
inserting "glyphs" that you could use and/or extend this hash array:

 Excerptions from "unichars.el":
(defvar unicode-character-list
  '(
;Codept   Unicode nameISO Name
(#x00 "NULL"   nil )
...
   (#x00fb92 "ARABIC LETTER GAF ISOLATED FORM"nil )
(#x00fb93 "ARABIC LETTER GAF FINAL FORM"   nil )
(#x00fb94 "ARABIC LETTER GAF INITIAL FORM" nil )
(#x00fb95 "ARABIC LETTER GAF MEDIAL FORM"  nil )
(#x00fb96 "ARABIC LETTER GUEH ISOLATED FORM"   nil )
...
* See this wonderful extension/new take on this too:
http://proofgeneral.inf.ed.ac.uk/releases/ProofGeneral-3.7/x-symbol/lisp/x-symbol-unichars.el
--so suggest looking at x-symbol-unichars.el, unichars.el and maybe
x-symbol.el and maybe then input UNICODE "glyphs" into your table.
Can you extend it to Asian/Chinese/Tamil chars?
(I don't see any in the files x-symbol-unichars.el, unichars.el, x-symbol.el)

*** Last idea: I've put ticker-tape .GIF files in EMACS OrgMode
buffers--you could put an infinite scrolling ticker tape of AsianChars
in fixed-width .GIF files with say a 16x16 pixel window (or wider) and
then know a priori that the table would remain covered down--when you
view it in an EMACS OrgMode buffer--regardless of what text you put in
it (This is probably not what you want though--but if you are doing a
presentation or tutorial of some sort and you want to show your table
with scrolling notes in table cells, then it can work for you--I've
done it.)  You can use ImageMagick to create the .GIF files--of the
scrolling Asian text.


_ ElBaradei,  3 minutes ago:
  ١٠ شهور قبل إحالة قضية الشهيد سيد بلال
  للجنايات المتهم فيها ٥ من ضباط أمن الدولة هرب
  معظمهم الى الخارج. شئ مخزى // from Twitter for
  iPad [Cairo, Egypt]


On Fri, Oct 28, 2011 at 10:25 AM, Rustom Mody  wrote:
> Jambunathan wrote:
>>
>> Book seems like an interesting read. For me to go from frame message ->

> The wikipedia page:
> http://en.wikipedia.org/wiki/Talk:Douglas_Hofstadter#Inspirational
>

Re: [O] Feature Request: Disable auto-insert-mode exporting

[Carsten Dominik]

On 28.10.2011, at 18:45, Nick Dokos wrote:

> Darlan Cavalcante Moreira  wrote:
> 
>> 
>> Thanks Carsten,
>> That's great.
>> 
>> I tested without the advice it worked as expected for both exporters.
>> 
>> I would be surprised if anyone could give a reason to keep the AUCTeX query
>> or the auto-insert stuff, at least without modifying org-export. That's
>> because the export process replaces anything in the new buffer, be it the
>> file variables inserted by AUCTeX or the content inserted by auto-insert,
>> with the result from the export.
>> 
> 
> I presume there are no problems if somebody is *not* using auctex and/or
> auto-insert: correct? If org-export does essentially the same thing that
> the advice below does, it should not cause any problems, but...

It works exactly the same, just temporarily turning off these features for
the creation of new export buffers.

> 
> OTOH, if it breaks innocent users, then it should not be implemented: that
> would be the only reason I can think of.

I don't expect any problems, but we will see.

- Carsten

> 
> Nick
> 
>> --
>> Darlan
>> 
>> At Fri, 28 Oct 2011 10:43:00 +0200,
>> Carsten Dominik  wrote:
>>> 
>>> 
>>> On 28.10.2011, at 06:49, Darlan Cavalcante Moreira wrote:
>>> 
 
 Thanks Nick,
 
 You right, the master file question comes from auctex. But with your code
 it's simple to add the relevant variable to solve the issue. The final
 function is
 --8<---cut here---start->8---
 (defadvice org-export (around org-export-no-auto-insert)
 (let ((auto-insert nil)
   (TeX-master t)
   )
   ad-do-it))
>>> 
>>> 
>>> Ahh, that has been bothering me for many years, thanks for this solution.
>>> I have made this behavior (as well as turning off auto-insert) now
>>> standard in Org-mode, so the advice will no longer be needed.
>>> 
>>> Or, can anyone come up with a reason why the AUCTeX query or auto-insert
>>> stuff could be useful when creating new files during Org-mode export?
>>> 
>>> - Carsten
>>> 
>>> 
 
 (ad-activate 'org-export)
 --8<---cut here---end--->8---
 
 --
 Darlan
 
 At Thu, 27 Oct 2011 17:03:55 -0400,
 Nick Dokos  wrote:
> 
> Darlan Cavalcante Moreira  wrote:
> 
>> 
>> I consider auto-insert-mode to be a very useful feature in Emacs and it
>> works great in most situations, except when exporting an org-mode buffer.
>> 
>> If I export to PDF or HTML, for instance, then org-mode creates a TeX or 
>> an
>> HTML buffer and auto-insert kicks-in in both cases (asking for the title 
>> in
>> the HTML buffer, or the master file in the TeX buffer). Whatever I write
>> will be overwritten by the org-mode exporter and the file exports just
>> fine, but this interruption is annoying.
>> 
> 
> I don't think the master file question comes from auto-insert - I believe
> it comes from auctex. In particular, I get the question but I don't have
> auto-insert enabled for latex.
> 
>> I suppose I could create a function that disable auto-insert-mode, call
>> org-export and then re-enable auto-insert-mode, but maybe this should be
>> the default behaviour of org-mode export. Does this make sense?
>> 
> 
> You can advise org-export:
> 
> (defadvice org-export (around org-export-no-auto-insert)
> (let ((auto-insert nil))
>   ad-do-it))
> 
> (ad-activate 'org-export)
> 
> should do it (untested).
> 
> Nick
 
>>> 
>> 
> tex

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

The attached patch implements these changes, please see the patch
comment as it contains all of the pertinent information.

If any brave volunteers would be willing to test this patch locally
before I apply it to the Org-mode git repository that would be greatly
appreciated.

Thanks to the test suite the most egregious bugs introduced by my first
version of this patch have already been caught and fixed.

Cheers -- Eric

>From a708aced9e29504637ac1d2ce3203fb796081a7e Mon Sep 17 00:00:00 2001
From: Eric Schulte 
Date: Fri, 28 Oct 2011 10:44:21 -0600
Subject: [PATCH] removing code block, results and call-line synonyms -- BREAKING CHANGE

Following a round of on-list discussion many code block synonyms have
been removed, moving forward the following syntax is valid.

- call lines are specified with #+call:
- code blocks are named with #+name:
- results are named with #+name:, however results generated by a code
  block may still be labeled with #+results:, and tables named with
  #+tblname: will be considered to be named results

The following function may be used to update an existing Org-mode
buffer to the new syntax.

  (defun update-org-buffer ()
"Update an Org-mode buffer to the new data, code block and call line syntax."
(interactive)
(save-excursion
  (flet ((to-re (lst) (concat "^[ \t]*#\\+" (regexp-opt lst t)
  "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*"))
 (update (re new)
 (goto-char (point-min))
 (while (re-search-forward re nil t)
   (replace-match new nil nil nil 1
(let ((old-re (to-re '("RESULTS" "DATA" "SRCNAME" "SOURCE")))
  (lob-re (to-re '("LOB")))
  (case-fold-search t))
  (update old-re "name")
  (update lob-re "call")

Note: If an old version of Org-mode (e.g., the one shipped with Emacs)
  is installed on your system many of the important variables will
  be pre-defined with a defvar and *will not* have their values
  automatically updated, these include the following.
  - org-babel-data-names
  - org-babel-result-regexp
  - org-babel-src-block-regexp
  - org-babel-src-name-regexp
  - org-babel-src-name-w-name-regexp
  It may be necessary to either remove the source code of older
  versions of Org-mode, or to explicitly evaluate the ob.el file.

* lisp/ob-exp.el (org-exp-res/src-name-cleanup): Updated
  Documentation.
* lisp/ob-lob.el (org-babel-block-lob-one-liner-regexp): Updated
  regular expression.
  (org-babel-inline-lob-one-liner-regexp): Updated regular expression.
* lisp/ob-ref.el (org-babel-ref-resolve): Notice when something that
  looks like a data results may actually be a code block.
* lisp/ob-table.el: Updated documentation.
* lisp/ob.el (org-babel-src-name-regexp): Simplified regexp.
  (org-babel-get-src-block-info): Updated match strings.
  (org-babel-data-names): Simplified acceptable names.
  (org-babel-find-named-block): Indentation.
  (org-babel-find-named-result): Updated to not return a code block as
  a result.
* lisp/org.el (org-fontify-meta-lines-and-blocks-1): Removing
  references to old syntactic elements.
  (org-additional-option-like-keywords): Removing references to old
  syntactic elements.
* contrib/babel/library-of-babel.org: Updated to make use of the new
  syntax.
* testing/examples/babel-dangerous.org: Updated to make use of the new
  syntax.
* testing/examples/babel.org: Updated to make use of the new syntax.
* testing/examples/ob-awk-test.org: Updated to make use of the new
  syntax.
* testing/examples/ob-fortran-test.org: Updated to make use of the new
  syntax.
* testing/lisp/test-ob.el: Removed two bad tests which tested the
  literal values of old regular expressions rather than their
  behavior.
---
 contrib/babel/library-of-babel.org   |   48 +-
 lisp/ob-exp.el   |2 +-
 lisp/ob-lob.el   |   13 +
 lisp/ob-ref.el   |4 +++
 lisp/ob-table.el |2 +-
 lisp/ob.el   |   30 -
 lisp/org.el  |9 ++
 testing/examples/babel-dangerous.org |5 +++-
 testing/examples/babel.org   |   30 ++--
 testing/examples/ob-awk-test.org |4 +-
 testing/examples/ob-fortran-test.org |4 +-
 testing/lisp/test-ob.el  |   42 -
 12 files changed, 75 insertions(+), 118 deletions(-)

diff --git a/contrib/babel/library-of-babel.org b/contrib/babel/library-of-babel.org
index 2db9d4c..571eb70 100644
--- a/contrib/babel/library-of-babel.org
+++ b/contrib/babel/library-of-babel.org
@@ -22,7 +22,7 @@
 
 A collection of simple utility functions:
 
-#+srcname: echo
+#+name: echo
 #+begin_src emacs-lisp :var input="echo'd"
   input
 #+end_src
@@ -35,7 +35,7 @@ Read the contents of the file at =file=

Re: [O] Feature Request: Disable auto-insert-mode exporting

[Nick Dokos]

Darlan Cavalcante Moreira  wrote:

> 
> Thanks Carsten,
> That's great.
> 
> I tested without the advice it worked as expected for both exporters.
> 
> I would be surprised if anyone could give a reason to keep the AUCTeX query
> or the auto-insert stuff, at least without modifying org-export. That's
> because the export process replaces anything in the new buffer, be it the
> file variables inserted by AUCTeX or the content inserted by auto-insert,
> with the result from the export.
> 

I presume there are no problems if somebody is *not* using auctex and/or
auto-insert: correct? If org-export does essentially the same thing that
the advice below does, it should not cause any problems, but...

OTOH, if it breaks innocent users, then it should not be implemented: that
would be the only reason I can think of.

Nick

> --
> Darlan
> 
> At Fri, 28 Oct 2011 10:43:00 +0200,
> Carsten Dominik  wrote:
> > 
> > 
> > On 28.10.2011, at 06:49, Darlan Cavalcante Moreira wrote:
> > 
> > > 
> > > Thanks Nick,
> > > 
> > > You right, the master file question comes from auctex. But with your code
> > > it's simple to add the relevant variable to solve the issue. The final
> > > function is
> > > --8<---cut here---start->8---
> > > (defadvice org-export (around org-export-no-auto-insert)
> > >  (let ((auto-insert nil)
> > >(TeX-master t)
> > >)
> > >ad-do-it))
> > 
> > 
> > Ahh, that has been bothering me for many years, thanks for this solution.
> > I have made this behavior (as well as turning off auto-insert) now
> > standard in Org-mode, so the advice will no longer be needed.
> > 
> > Or, can anyone come up with a reason why the AUCTeX query or auto-insert
> > stuff could be useful when creating new files during Org-mode export?
> > 
> > - Carsten
> > 
> > 
> > > 
> > > (ad-activate 'org-export)
> > > --8<---cut here---end--->8---
> > > 
> > > --
> > > Darlan
> > > 
> > > At Thu, 27 Oct 2011 17:03:55 -0400,
> > > Nick Dokos  wrote:
> > >> 
> > >> Darlan Cavalcante Moreira  wrote:
> > >> 
> > >>> 
> > >>> I consider auto-insert-mode to be a very useful feature in Emacs and it
> > >>> works great in most situations, except when exporting an org-mode 
> > >>> buffer.
> > >>> 
> > >>> If I export to PDF or HTML, for instance, then org-mode creates a TeX 
> > >>> or an
> > >>> HTML buffer and auto-insert kicks-in in both cases (asking for the 
> > >>> title in
> > >>> the HTML buffer, or the master file in the TeX buffer). Whatever I write
> > >>> will be overwritten by the org-mode exporter and the file exports just
> > >>> fine, but this interruption is annoying.
> > >>> 
> > >> 
> > >> I don't think the master file question comes from auto-insert - I believe
> > >> it comes from auctex. In particular, I get the question but I don't have
> > >> auto-insert enabled for latex.
> > >> 
> > >>> I suppose I could create a function that disable auto-insert-mode, call
> > >>> org-export and then re-enable auto-insert-mode, but maybe this should be
> > >>> the default behaviour of org-mode export. Does this make sense?
> > >>> 
> > >> 
> > >> You can advise org-export:
> > >> 
> > >> (defadvice org-export (around org-export-no-auto-insert)
> > >>  (let ((auto-insert nil))
> > >>ad-do-it))
> > >> 
> > >> (ad-activate 'org-export)
> > >> 
> > >> should do it (untested).
> > >> 
> > >> Nick
> > > 
> > 
> 
tex

Re: [O] Feature Request: Disable auto-insert-mode exporting

[Darlan Cavalcante Moreira]

Thanks Carsten,
That's great.

I tested without the advice it worked as expected for both exporters.

I would be surprised if anyone could give a reason to keep the AUCTeX query
or the auto-insert stuff, at least without modifying org-export. That's
because the export process replaces anything in the new buffer, be it the
file variables inserted by AUCTeX or the content inserted by auto-insert,
with the result from the export.

--
Darlan

At Fri, 28 Oct 2011 10:43:00 +0200,
Carsten Dominik  wrote:
> 
> 
> On 28.10.2011, at 06:49, Darlan Cavalcante Moreira wrote:
> 
> > 
> > Thanks Nick,
> > 
> > You right, the master file question comes from auctex. But with your code
> > it's simple to add the relevant variable to solve the issue. The final
> > function is
> > --8<---cut here---start->8---
> > (defadvice org-export (around org-export-no-auto-insert)
> >  (let ((auto-insert nil)
> >(TeX-master t)
> >)
> >ad-do-it))
> 
> 
> Ahh, that has been bothering me for many years, thanks for this solution.
> I have made this behavior (as well as turning off auto-insert) now
> standard in Org-mode, so the advice will no longer be needed.
> 
> Or, can anyone come up with a reason why the AUCTeX query or auto-insert
> stuff could be useful when creating new files during Org-mode export?
> 
> - Carsten
> 
> 
> > 
> > (ad-activate 'org-export)
> > --8<---cut here---end--->8---
> > 
> > --
> > Darlan
> > 
> > At Thu, 27 Oct 2011 17:03:55 -0400,
> > Nick Dokos  wrote:
> >> 
> >> Darlan Cavalcante Moreira  wrote:
> >> 
> >>> 
> >>> I consider auto-insert-mode to be a very useful feature in Emacs and it
> >>> works great in most situations, except when exporting an org-mode buffer.
> >>> 
> >>> If I export to PDF or HTML, for instance, then org-mode creates a TeX or 
> >>> an
> >>> HTML buffer and auto-insert kicks-in in both cases (asking for the title 
> >>> in
> >>> the HTML buffer, or the master file in the TeX buffer). Whatever I write
> >>> will be overwritten by the org-mode exporter and the file exports just
> >>> fine, but this interruption is annoying.
> >>> 
> >> 
> >> I don't think the master file question comes from auto-insert - I believe
> >> it comes from auctex. In particular, I get the question but I don't have
> >> auto-insert enabled for latex.
> >> 
> >>> I suppose I could create a function that disable auto-insert-mode, call
> >>> org-export and then re-enable auto-insert-mode, but maybe this should be
> >>> the default behaviour of org-mode export. Does this make sense?
> >>> 
> >> 
> >> You can advise org-export:
> >> 
> >> (defadvice org-export (around org-export-no-auto-insert)
> >>  (let ((auto-insert nil))
> >>ad-do-it))
> >> 
> >> (ad-activate 'org-export)
> >> 
> >> should do it (untested).
> >> 
> >> Nick
> > 
> 

Re: [O] Elisp programming style

[Thorsten]

Tassilo Horn  writes:

> And I wouldn't tell multiple similar let-bindings duplicate code.

I have to get used to that, at first sight it looks like there is
redundancy everywhere. But its more from the Java perspective, from the
more functional perspective it makes sense.

cheers
-- 
Thorsten

Re: [O] Elisp programming style

[Thorsten]

Nick Dokos  writes:

> Not a problem - you can't predict the future. You do the best you can
> with your current knowledge. You can always refactor in the future:
> that's one reason that having the source code around is important.  When
> you refactor, you may be cursing the original author for the "bad"
> decicions, but c'est la vie: at least, you have chosen a system where
> *you* can do that and not depend on a third party: they might not even
> be alive, let alone willing to do what you want.

Thats really great about Emacs lisp - everything is so easily
accessible, it seems like no big deal to change something. I still have
to get rid of the reflex to factor out every duplication of code that I
see. Lisp is not Java...

cheers
-- 
Thorsten

Re: [O] Elisp programming style

[Thorsten]

Eric Schulte  writes:

Hi Eric, 

> Hmmm, this looks suspiciously like the case in some Babel functions :)

well ... ;)

> in which we originally has instances of the first style and then had to
> manually transition to the second.  IMO the first is very poor form, the
> variables are technically "free variables" when defined in the helper,
> and just through undocumented variable capture does the execution work
> out correctly, this can lead to unpleasant bugs.
>
> The means the helper may only be used when variables of certain names
> are in scope.
>
> If you do want to use a helper which uses variables in scope which
> aren't passed as arguments (again just my opinion) you should defined
> the helper function using `flet' *inside* of the main function and the
> scope of the variables.

That sounds like an operational prescription to me, and I think will
follow this advice in the future.

>> Would that be considered bad style from the original author, or is that
>> up to personal choice and not considered a problem?
>>
>
> I don't believe we have an official canon of such rules, but personally
> I would consider this to be bad style.  If the helper function is only
> used in one main function then it should be defined using flet, if it is
> used across multiple functions then the in-scope variables should be
> passed as explicit arguments (preferably with names other than those
> which it has in scope so you can be sure you are actually using the
> arguments).
>
> Finally, I believe the emacs-lisp compiler would complain about such
> free variables.
>
> Hope this helps, Best -- Eric

yes that helped, thanks

cheers
-- 
Thorsten

Re: [O] [PATCH] Stealth org-link-search

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> I don't think there is a decent way to search for a link destination
> without modifying buffer's visibility around match.  This can be very
> annoying when resolving links in background.

Indeed -- I've just applied this patch, thanks for it!

-- 
 Bastien

Re: [O] Bug: [testing] missing dependency [7.7 (release_7.7.340.ga342)]

[Eric Schulte]

Bastien  writes:

> Hi Dave,
>
> Dave Abrahams  writes:
>
>>> `org-test-load' works fine here without requiring the ESS package.
>>>
>>> Can you check again?
>>
>> I probably don't have time, sorry.  Did you try this with a fresh
>> emacs -Q?
>
> Yes -- and there is no ESS dependancy, unless I missed something.
>

The tests for R code blocks (which are the only ones which require ESS)
will simply not load if ESS is not present.

Best -- Eric

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

Re: [O] org-lrn

[Bastien]

Hi Johannes,

Johannes Hess  writes:

> Hah, of course i did not know about org-drill, that one looks pretty
> good. :)

You just need to make org-lrn better than org-drill now :) 

In any case, if you feel like org-lrn should be listed here

  http://orgmode.org/worg/org-contrib/index.html

please send a patch against this file:

  http://repo.or.cz/w/Worg.git/blob_plain/HEAD:/org-contrib/index.org

Thanks!

-- 
 Bastien

Re: [O] Links to C/C++ source code lines

[Bastien]

Hi Rafal,

Rafal  writes:

> Bastien  altern.org> writes:
>
>> Looks nice, thanks.  Just wondering: are you aware of the "A.3 Adding
>> hyperlink types" section in the manual?  You core uses advice instead 
>> of the `org-add-link-type' function -- is that on purpose?
>
> No, I missed that paragraph. That would be a cleaner solution-
> I'll take a look at it. Thank for the hint!

Great -- let us know if you come up with an updated version of 
your tool!

Regards,

-- 
 Bastien

Re: [O] Byte compiler warnings

[Bastien]

Hi Andrei,

Andrei Jirnyi  writes:

> A few warnings from Emacs 23.2.1 here:

Thanks.  I fixed most of them.

> Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-C.el at Mon Oct 
> 24 18:20:36 2011
> Entering directory `/home/xx/.emacs.d/elpa/org-20111024/'
>
> Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-calc.el at Mon 
> Oct 24 18:20:36 2011
>
> In end of data:
> ob-calc.el:105:1:Warning: the following functions are not known to be 
> defined:
> calc-store-into, calc-recall, math-evaluate-expr

Fixed.

> Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-shen.el at Mon 
> Oct 24 18:20:38 2011
>
> In org-babel-execute:shen:
> ob-shen.el:68:32:Warning: reference to free variable `result-params'
> ob-shen.el:72:19:Warning: reference to free variable `result'

Not fixed.

> Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-agenda.el at 
> Mon Oct 24 18:20:39 2011
>
> In org-agenda-list:
> org-agenda.el:3555:26:Warning: `org-agenda-ndays' is an obsolete variable 
> (as
> of Emacs 24.1); use `org-agenda-span' instead.

Not fixed.

> In org-agenda-get-todos:
> org-agenda.el:4596:26:Warning: reference to free variable
> `org-heading-keyword-regexp-format'

Fixed.

> In org-agenda-goto-today:
> org-agenda.el:6410:59:Warning: `org-agenda-ndays' is an obsolete variable 
> (as
> of Emacs 24.1); use `org-agenda-span' instead.
>
> In org-agenda-reset-view:
> org-agenda.el:6495:36:Warning: `org-agenda-ndays' is an obsolete variable 
> (as
> of Emacs 24.1); use `org-agenda-span' instead.

Not fixed.

> Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-colview.el at 
> Mon Oct 24 18:20:41 2011
>
> In org-columns-capture-view:
> org-colview.el:1155:32:Warning: reference to free variable
> `org-heading-keyword-regexp-format'
> org-colview.el:1160:33:Warning: reference to free variable
> `org-heading-regexp'

Fixed.

> Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-compat.el at 
> Mon Oct 24 18:20:41 2011
>
> In org-find-library-name:
> org-compat.el:341:14:Warning: find-library called with 3 arguments, but
> accepts only 1

No fix needed.

> Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-docbook.el at 
> Mon Oct 24 18:20:41 2011
>
> In org-export-as-docbook:
> org-docbook.el:502:31:Warning: reference to free variable
> `org-heading-keyword-regexp-format'

Fixed.

> Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-exp.el at Mon 
> Oct 24 18:20:42 2011
>
> In org-export-protect-quoted-subtrees:
> org-exp.el:1641:31:Warning: reference to free variable
> `org-heading-keyword-regexp-format'
>
> In org-export-remove-comment-blocks-and-subtrees:
> org-exp.el:1936:31:Warning: reference to free variable
> `org-heading-keyword-regexp-format'

Fixed.

> Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-html.el at Mon 
> Oct 24 18:20:47 2011
>
> In org-export-as-html:
> org-html.el:1179:31:Warning: reference to free variable
> `org-heading-keyword-regexp-format'

Fixed.

Please report other problems.

Thanks!

-- 
 Bastien

Re: [O] Bug: [testing] missing dependency [7.7 (release_7.7.340.ga342)]

[Bastien]

Hi Dave,

Dave Abrahams  writes:

>> `org-test-load' works fine here without requiring the ESS package.
>>
>> Can you check again?
>
> I probably don't have time, sorry.  Did you try this with a fresh
> emacs -Q?

Yes -- and there is no ESS dependancy, unless I missed something.

Best,

-- 
 Bastien

Re: [O] [PATCH] org-crypt: when running org-decrypt-entry, only run auto-save-mode check if on an encrypted entry

[Bastien]

Hi Pieter,

Pieter Praet  writes:

> BTW, my FSF copyright assignment is completed (assignment number
> #705083) so I should probably be added to the list of signees [1].

I just added you -- thanks for the reminder!

-- 
 Bastien

Re: [O] [PATCH] Adding features to contrib/lisp/org-collector.el (propview)

[Bastien]

Jonathan BISSON  writes:

> Here it is,

Thanks for the quick reply -- since Eric also replied, I let 
him decide about this!

Best,

-- 
 Bastien

Re: [O] Patch: Mark org-diary-class as obsolete and skip entries on holidays in org-class

[Bastien]

Achim Gratz  writes:

> This change introduced a new warning:
>
> In end of data:
> org-agenda.el:8536:1:Warning: the function `calendar-check-holidays' is not
> known to be defined. 

Fixed, thanks.

-- 
 Bastien

Re: [O] Bug? in the latest revision of org

[Bastien]

Hi Paul,

Paul Sexton  writes:

> The code needs to change to something like:
>
>((and org-return-follows-link
>  (let ((tprop (get-text-property (point) 'face)))
>  (or (eq tprop 'org-link)
>  (and (listp tprop) (memq 'org-link tprop)

thanks for the analysis and the fix -- I committed it right
now.  And thanks to Marcelo for the report !

-- 
 Bastien

Re: [O] [PATCH] Adding features to contrib/lisp/org-collector.el (propview)

[Jonathan BISSON]

On 10/28/2011 04:32 PM, Bastien wrote:
> Hi Jonathan,
> 
> Jonathan BISSON  writes:
> 
>> I did a small patch for org-collector.
> 
> Thanks for this -- can you resend the patch by attaching 
> it, instead of inserting it in the body of the email?  It 
> is not readable here.
> 
> Thanks!
> 

Here it is,

121a122,123
> 	(noquote (plist-get params :noquote))
> 	(colnames (plist-get params :colnames))
132a135
> 	  (setq stringformat (if noquote "%s" "%S"))
134c137,138
< 		   (org-propview-collect cols conds match scope inherit)))
---
> 		   (org-propview-collect cols stringformat conds match scope inherit 
> 	 (if colnames colnames cols)) stringformat))
170c174
< (defun org-propview-collect (cols &optional conds match scope inherit)
---
> (defun org-propview-collect (cols stringformat &optional conds match scope inherit colnames)
194,195c198,199
<   (mapcar (lambda (el) (format "%S" el)) cols) ;; output headers
<   'hline) ;; 
---
>   (if colnames colnames (mapcar (lambda (el) (format stringformat el)) cols))
>'hline) ;; 
214c218
< (defun org-propview-to-table (results)
---
> (defun org-propview-to-table (results stringformat)
221c225
< 	(mapcar (lambda (el) (format "%S" el)) row)))
---
> 	(mapcar (lambda (el) (format stringformat el)) row)))


signature.asc
Description: OpenPGP digital signature

Re: [O] Elisp programming style

[Eric Schulte]

Tassilo Horn  writes:

> Thorsten  writes:
>
>>> Too bad you didn't give any concrete examples.
>>
>> The problem can be described easily: 
>>
>> problem-specific helper-funcions (some redundancy avoided)
>> ,---
>> | (defun main-function (args)   
>> | (let ((var (assoc :key1 args)))  ; extracting var once
>> | ...   
>> | (helper-function1 ...) ; inside let using var 
>> | (helper-function2 ...) ; inside let using var 
>> | ))
>> |   
>> | (defun helper-function1 ()
>> | ...   
>> | ) 
>> |   
>> | (defun helper-function2 ()
>> | ...   
>> | ) 
>> `---
>>
>> vs
>>
>> standalone helper-functions (but redundancy)
>> ,-
>> | (defun main-function (args) 
>> | (let ((value (assoc :key1 args))   ; extracting var 1st time
>> | ... 
>> | )   
>> | (helper-function1 ...) ; outside let
>> | (helper-function2 ...) ; outside let
>> | )   
>> | 
>> | (defun helper-function1 (args)  
>> | (let ((var (assoc :key1 args)))  ; extracting var 2nd time  
>> | ... 
>> | ))  
>> | 
>> | (defun helper-function2 (args)  
>> | (let ((var (assoc :key1 args)))  ; extracting var 3rd time  
>> | ... 
>> | ))  
>> `-
>
> That's still very vague.  If `args' is some structure that has some
> meaning and its parts belong together, say, an org entry, then it makes
> sense to have the helper functions defined on that structure in order to
> provide a consistent interface throughout the library.  And I wouldn't
> tell multiple similar let-bindings duplicate code.
>

To clarify my earlier reply, I would agree with Tassilo above.  If args
is a global variable (declared with defvar or defconst) then using it
without accepting it as an argument is not a problem (and the emacs-lisp
compiler will not complain).

Best -- Eric

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

Re: [O] [PATCH] Adding features to contrib/lisp/org-collector.el (propview)

[Eric Schulte]

Hi Jonathan,

This does sound useful.  Unfortunately your email client seems to have
mangled the patch, could you resend with the patch attached rather than
pasted inline?

Thanks -- Eric

Jonathan BISSON  writes:

> Hi there,
>
>
> I did a small patch for org-collector.
>
> Here are the changes :
> - Adding a :colnames property, allowing to give the column names
> (instead of displaying the function used to populate the table)
> - Adding a :noquote property, allowing to remove the double quotes
> around strings
>
> I hope some of you would find it useful.
>
> 121a122,123
>>  (noquote (plist-get params :noquote))
>>  (colnames (plist-get params :colnames))
> 132a135
>>(setq stringformat (if noquote "%s" "%S"))
> 134c137,138
> <(org-propview-collect cols conds match scope inherit)))
> ---
>> (org-propview-collect cols stringformat conds match scope
> inherit
>>   (if colnames colnames cols)) 
>> stringformat))
> 170c174
> < (defun org-propview-collect (cols &optional conds match scope inherit)
> ---
>> (defun org-propview-collect (cols stringformat &optional conds match
> scope inherit colnames)
> 194,195c198,199
> <   (mapcar (lambda (el) (format "%S" el)) cols) ;; output headers
> <   'hline) ;; 
> ---
>>   (if colnames colnames (mapcar (lambda (el) (format stringformat
> el)) cols))
>>'hline) ;; 
> 214c218
> < (defun org-propview-to-table (results)
> ---
>> (defun org-propview-to-table (results stringformat)
> 221c225
> < (mapcar (lambda (el) (format "%S" el)) row)))
> ---
>>  (mapcar (lambda (el) (format stringformat el)) row)))
>

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

Re: [O] Elisp programming style

[Eric Schulte]

>
> The problem can be described easily: 
>
> problem-specific helper-funcions (some redundancy avoided)
> ,---
> | (defun main-function (args)   
> | (let ((var (assoc :key1 args)))  ; extracting var once
> | ...   
> | (helper-function1 ...) ; inside let using var 
> | (helper-function2 ...) ; inside let using var 
> | ))
> |   
> | (defun helper-function1 ()
> | ...   
> | ) 
> |   
> | (defun helper-function2 ()
> | ...   
> | ) 
> `---
>
> vs
>
> standalone helper-functions (but redundancy)
> ,-
> | (defun main-function (args) 
> | (let ((value (assoc :key1 args))   ; extracting var 1st time
> | ... 
> | )   
> | (helper-function1 ...) ; outside let
> | (helper-function2 ...) ; outside let
> | )   
> | 
> | (defun helper-function1 (args)  
> | (let ((var (assoc :key1 args)))  ; extracting var 2nd time  
> | ... 
> | ))  
> | 
> | (defun helper-function2 (args)  
> | (let ((var (assoc :key1 args)))  ; extracting var 3rd time  
> | ... 
> | ))  
> `-
>

Hmmm, this looks suspiciously like the case in some Babel functions :)
in which we originally has instances of the first style and then had to
manually transition to the second.  IMO the first is very poor form, the
variables are technically "free variables" when defined in the helper,
and just through undocumented variable capture does the execution work
out correctly, this can lead to unpleasant bugs.

The means the helper may only be used when variables of certain names
are in scope.

If you do want to use a helper which uses variables in scope which
aren't passed as arguments (again just my opinion) you should defined
the helper function using `flet' *inside* of the main function and the
scope of the variables.

>
>
>> In general, if the helper function is only used in a single place and
>> isn't likely to be more generally useful, there might be no reason for
>> it to be a standalone function at all (other than modular programming,
>> which is always a good idea IMO).
>>
>> OTOH, if the helper function _is_ standalone and used in multiple
>> places, then there is no "redundancy", so I'm really not sure what you
>> mean.
>
> Is there a policy? Lets say, an org-library author thinks his helper
> functions will be of no use for nobody else and designs them
> non-standalone. A few years later somebody wants to write a similar
> library and trys to reuse some of the old helper functions, to no avail. 
>
> Would that be considered bad style from the original author, or is that
> up to personal choice and not considered a problem?
>

I don't believe we have an official canon of such rules, but personally
I would consider this to be bad style.  If the helper function is only
used in one main function then it should be defined using flet, if it is
used across multiple functions then the in-scope variables should be
passed as explicit arguments (preferably with names other than those
which it has in scope so you can be sure you are actually using the
arguments).

Finally, I believe the emacs-lisp compiler would complain about such
free variables.

Hope this helps, Best -- Eric

>
> cheers

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

Re: [O] Elisp programming style

[Tassilo Horn]

Thorsten  writes:

>> Too bad you didn't give any concrete examples.
>
> The problem can be described easily: 
>
> problem-specific helper-funcions (some redundancy avoided)
> ,---
> | (defun main-function (args)   
> | (let ((var (assoc :key1 args)))  ; extracting var once
> | ...   
> | (helper-function1 ...) ; inside let using var 
> | (helper-function2 ...) ; inside let using var 
> | ))
> |   
> | (defun helper-function1 ()
> | ...   
> | ) 
> |   
> | (defun helper-function2 ()
> | ...   
> | ) 
> `---
>
> vs
>
> standalone helper-functions (but redundancy)
> ,-
> | (defun main-function (args) 
> | (let ((value (assoc :key1 args))   ; extracting var 1st time
> | ... 
> | )   
> | (helper-function1 ...) ; outside let
> | (helper-function2 ...) ; outside let
> | )   
> | 
> | (defun helper-function1 (args)  
> | (let ((var (assoc :key1 args)))  ; extracting var 2nd time  
> | ... 
> | ))  
> | 
> | (defun helper-function2 (args)  
> | (let ((var (assoc :key1 args)))  ; extracting var 3rd time  
> | ... 
> | ))  
> `-

That's still very vague.  If `args' is some structure that has some
meaning and its parts belong together, say, an org entry, then it makes
sense to have the helper functions defined on that structure in order to
provide a consistent interface throughout the library.  And I wouldn't
tell multiple similar let-bindings duplicate code.

But again, that's only my very abstract point of view.  Given a concrete
example, my opinion might be completely upside-down. ;-)

Bye,
Tassilo

Re: [O] Text preceding first headline is well/not exported

[Bastien]

Hi Sébastien,

"Sebastien Vauban"  writes:

> But, anyway, be it nil or not, I'd expect the behavior to be the same in both
> exporters.

Me too :)

> Can someone confirm this behavior?

I cannot reproduce this behavior with your test file.

Can you reproduce this with emacs -Q?

-- 
 Bastien

Re: [O] [PATCH] Adding features to contrib/lisp/org-collector.el (propview)

[Bastien]

Hi Jonathan,

Jonathan BISSON  writes:

> I did a small patch for org-collector.

Thanks for this -- can you resend the patch by attaching 
it, instead of inserting it in the body of the email?  It 
is not readable here.

Thanks!

-- 
 Bastien

Re: [O] Elisp programming style

[Nick Dokos]

Thorsten  wrote:

> Štěpán Němec  writes:
> 
> > On Thu, 27 Oct 2011 20:03:22 +0200
> > Thorsten wrote:
> >
> >> Hi List, doing some Elisp programming (in an orgmode context)
> >> recently, the following question with regards to the 'accepted
> >> programming style' for Elisp concerned me:
> >>
> >> How independent and self-sustained should helper functions be?
> >>
> >> I found some redundancy in elisp code, e.g. several (main and helper)
> >> functions that do exactly the same thing to extract the same specific
> >> args out of an argument list. My first reaction was, to factor out
> >> this extraction into the main function, and then call the helper
> >> functions from inside a (let ...) environment where the extracted
> >> args are stored in a local variable.
> >>
> >> But then I recognised, that the helper functions cannot be called
> >> independently anymore, but only make sense when called from this one
> >> main function with its local bindings.
> >>
> >> Is there a kind of convention in a case like this? Like: "Make every
> >> function, even a helper function, independent, and don't care about
> >> redundancy"? Just being curious
> >
> > Too bad you didn't give any concrete examples.
> 
> The problem can be described easily: 
> 
> problem-specific helper-funcions (some redundancy avoided)
> ,---
> | (defun main-function (args)   
> | (let ((var (assoc :key1 args)))  ; extracting var once
> | ...   
> | (helper-function1 ...) ; inside let using var 
> | (helper-function2 ...) ; inside let using var 
> | ))
> |   
> | (defun helper-function1 ()
> | ...   
> | ) 
> |   
> | (defun helper-function2 ()
> | ...   
> | ) 
> `---
> 

You probably need let* though.

> vs
> 
> standalone helper-functions (but redundancy)
> ,-
> | (defun main-function (args) 
> | (let ((value (assoc :key1 args))   ; extracting var 1st time
> | ... 
> | )   
> | (helper-function1 ...) ; outside let
> | (helper-function2 ...) ; outside let
> | )   
> | 
> | (defun helper-function1 (args)  
> | (let ((var (assoc :key1 args)))  ; extracting var 2nd time  
> | ... 
> | ))  
> | 
> | (defun helper-function2 (args)  
> | (let ((var (assoc :key1 args)))  ; extracting var 3rd time  
> | ... 
> | ))  
> `-
> 
> 
> > In general, if the helper function is only used in a single place and
> > isn't likely to be more generally useful, there might be no reason for
> > it to be a standalone function at all (other than modular programming,
> > which is always a good idea IMO).
> >
> > OTOH, if the helper function _is_ standalone and used in multiple
> > places, then there is no "redundancy", so I'm really not sure what you
> > mean.
> 
> Is there a policy? Lets say, an org-library author thinks his helper
> functions will be of no use for nobody else and designs them
> non-standalone. A few years later somebody wants to write a similar
> library and trys to reuse some of the old helper functions, to no avail. 
>

No policy that I know of. It's very much a matter of taste, how complicated
the functions are, whether they perform something generic or something really
specific etc.

> Would that be considered bad style from the original author, or is that
> up to personal choice and not considered a problem?
> 

Not a problem - you can't predict the future. You do the best you can
with your current knowledge. You can always refactor in the future:
that's one reason that having the source code around is important.  When
you refactor, you may be cursing the original author for the "bad"
decicions, but c'est la vie: at least, you have chosen a s

[O] OT: collage of scripts [was: Re: table alignment failed for Asian char

[Rustom Mody]

Jambunathan wrote:

> Book seems like an interesting read. For me to go from frame message ->
> outer message -> inner message, I think I need to read the whole book
> and not just a fragment of it
>
> Just curious, is the book a standard regular or supplementary reading
> for courses in US. If yes, courses here could improve a lot. Such
> readings will make CS/Mathematics fun, fascinating and mysterious.
>

The wikipedia page:
http://en.wikipedia.org/wiki/Talk:Douglas_Hofstadter#Inspirational

discusses the question

This book is commonly considered to have inspired many students to begin
careers in computing...

Re: [O] Elisp programming style

[Thorsten]

Štěpán Němec  writes:

> On Thu, 27 Oct 2011 20:03:22 +0200
> Thorsten wrote:
>
>> Hi List, doing some Elisp programming (in an orgmode context)
>> recently, the following question with regards to the 'accepted
>> programming style' for Elisp concerned me:
>>
>> How independent and self-sustained should helper functions be?
>>
>> I found some redundancy in elisp code, e.g. several (main and helper)
>> functions that do exactly the same thing to extract the same specific
>> args out of an argument list. My first reaction was, to factor out
>> this extraction into the main function, and then call the helper
>> functions from inside a (let ...) environment where the extracted
>> args are stored in a local variable.
>>
>> But then I recognised, that the helper functions cannot be called
>> independently anymore, but only make sense when called from this one
>> main function with its local bindings.
>>
>> Is there a kind of convention in a case like this? Like: "Make every
>> function, even a helper function, independent, and don't care about
>> redundancy"? Just being curious
>
> Too bad you didn't give any concrete examples.

The problem can be described easily: 

problem-specific helper-funcions (some redundancy avoided)
,---
| (defun main-function (args)   
| (let ((var (assoc :key1 args)))  ; extracting var once
| ...   
| (helper-function1 ...) ; inside let using var 
| (helper-function2 ...) ; inside let using var 
| ))
|   
| (defun helper-function1 ()
| ...   
| ) 
|   
| (defun helper-function2 ()
| ...   
| ) 
`---

vs

standalone helper-functions (but redundancy)
,-
| (defun main-function (args) 
| (let ((value (assoc :key1 args))   ; extracting var 1st time
| ... 
| )   
| (helper-function1 ...) ; outside let
| (helper-function2 ...) ; outside let
| )   
| 
| (defun helper-function1 (args)  
| (let ((var (assoc :key1 args)))  ; extracting var 2nd time  
| ... 
| ))  
| 
| (defun helper-function2 (args)  
| (let ((var (assoc :key1 args)))  ; extracting var 3rd time  
| ... 
| ))  
`-


> In general, if the helper function is only used in a single place and
> isn't likely to be more generally useful, there might be no reason for
> it to be a standalone function at all (other than modular programming,
> which is always a good idea IMO).
>
> OTOH, if the helper function _is_ standalone and used in multiple
> places, then there is no "redundancy", so I'm really not sure what you
> mean.

Is there a policy? Lets say, an org-library author thinks his helper
functions will be of no use for nobody else and designs them
non-standalone. A few years later somebody wants to write a similar
library and trys to reuse some of the old helper functions, to no avail. 

Would that be considered bad style from the original author, or is that
up to personal choice and not considered a problem?

cheers
-- 
Thorsten

[O] [Accepted] Fix holidays symbol in org-class

[Carsten Dominik]

Patch 1013 (http://patchwork.newartisans.com/patch/1013/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3C87lis55l1h.fsf%40fastmail.fm%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [O] Fix holidays symbol in org-class
> Date: Fri, 28 Oct 2011 17:57:42 -
> From: Matt Lundin 
> X-Patchwork-Id: 1013
> Message-Id: <87lis55l1h@fastmail.fm>
> To: Org Mode 
> 
> * lisp/org-agenda.el: (org-class): Fix holidays symbol in org-class.
>   This was resulting in an "Bad sexp..." warning.
> 
> ---
> lisp/org-agenda.el |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index 66686f9..cbf8407 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -4907,7 +4907,7 @@ holidy will also be skipped."
>(progn
>  (require 'cal-iso)
>  (not (member (car (calendar-iso-from-absolute d)) skip-weeks
> - (not (and (memq `holidays' skip-weeks)
> + (not (and (memq 'holidays skip-weeks)
>  (calendar-check-holidays date)))
>   entry)))
>  
> 

[O] [PATCH] Fix holidays symbol in org-class

[Matt Lundin]

* lisp/org-agenda.el: (org-class): Fix holidays symbol in org-class.
  This was resulting in an "Bad sexp..." warning.
---
 lisp/org-agenda.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 66686f9..cbf8407 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4907,7 +4907,7 @@ holidy will also be skipped."
 (progn
   (require 'cal-iso)
   (not (member (car (calendar-iso-from-absolute d)) skip-weeks
- (not (and (memq `holidays' skip-weeks)
+ (not (and (memq 'holidays skip-weeks)
   (calendar-check-holidays date)))
  entry)))
 
-- 
1.7.7.1

Re: [O] How to install contributions to org-mode such as org-contacts?

[Marius Hofert]

Dear Brian,

thanks a lot. It's working now.

I followed the instructions, but (erroneously) thought that the copying to some 
folder and using load-path is not required. 

Cheers,

Marius

On 2011-10-28, at 14:23 , Brian van den Broek wrote:

> On 28 October 2011 14:07, Marius Hofert  wrote:
>> Hi,
>> 
>> I downloaded and successfully installed the latest version org-mode (M-x 
>> org-version shows 7.7). I was hoping to get org-contacts with it, too, but 
>> when putting (require 'org-contacs) in .emacs, I obtain:
>> 
>> Warning (initialization): An error occurred while loading 
>> `/Users/mhofert/.emacs':
>> 
>> File error: Cannot open load file, org-contacts
>> 
>> To ensure normal operation, you should investigate and remove the
>> cause of the error in your initialization file.  Start Emacs with
>> the `--debug-init' option to view a complete error backtrace.
>> 
>> Org-contacts is one of the contributions and can be found in org-7.7/contrib.
>> How can I install this org-mode contribution (on Mac OS X 10.7.2 with GNU 
>> Emacs 23.3 (9.0))?
>> 
>> I installed the latest org-mode version by setting (in ./Makefile):
>> 
>>  EMACS=/Applications/Emacs.app/Contents/MacOS//emacs
>>  lispdir=/Applications/Emacs.app/Contents/Resources/lisp/
>>  infodir=/Applications/Emacs.app/Contents/Resources/info
>> 
>> I checked the contribution README, but that didn't tell  me how to install 
>> org-mode ocntributions.
>> 
>> 
>> Cheers,
>> 
>> Marius
>> 
> 
> 
> Marius,
> 
> Do you do what the fine manual suggests?:
> 
> If you plan to use code from the contrib subdirectory, do a similar
> step for this directory:
> 
> (setq load-path (cons "~/path/to/orgdir/contrib/lisp" load-path))
> 
> http://orgmode.org/manual/Installation.html#Installation
> 
> Best,
> 
> Brian vdB

Re: [O] Columns view for org-tags-view

[Carsten Dominik]

Hello Ilya,

correct analysis, thanks, this is fixed in the git repo.

- Carsten

On 28.10.2011, at 12:59, Ilya Zonov wrote:

> Hello!
> 
> First of all I want say thank you for great emacs mode, which I using for 
> planning my life and job. Org-mode is the best!
> 
> I used 7.7 version with some patches from development version. For example, 
> patch which adds ability to cleanup items in agenda view 
> (org-columns-cleanup-item function).
> 
> I very like columns view, which I'm using for agenda views. So, I found that 
> %ITEM is not cleaned for agenda views are generated by org-tags-view. After 
> debuging and some investigation of org-tags-view code, I found that items in 
> agenda view generated by org-tags-view have no text-property 
> 'org-complex-heading-regexp. In this case org-columns-cleanup-item does not 
> clean items.
> 
> Then I found that properties for item are coped in org-scan-tags function. 
> But org-complex-heading-regexp property is not coped here. I suggest to add 
> this property in this function. Please, could you check my correction? I have 
> no big experience in lisp codding. So, maybe this change have some impact to 
> other parts of org-mode. Here is little patch for version 7.7:
> 
> *** /usr/share/emacs/site-lisp/org-mode/org.el
> --- Buffer org.el
> ***
> *** 12514,12519 
> --- 12514,12520 
> 'mouse-face 'highlight
> 'org-not-done-regexp org-not-done-regexp
> 'org-todo-regexp org-todo-regexp
> +   'org-complex-heading-regexp org-complex-heading-regexp
> 'help-echo
> (format "mouse-2 or RET jump to org file %s"
> (abbreviate-file-name
> 
> -- 
> Илья Зонов (Ilya Zonov) aka puzan
> Nizhny Novgorod, Russia

[O] export subtree-specific headers?

[Colin Fraizer]

I want to use particular LaTeX headers when I export a subtree. Is there a
way to do this? (EXPORT_TEXT is close, but I need stuff in the LaTeX
preamble, not in the document itself.)

 

--Colin

Re: [O] How to install contributions to org-mode such as org-contacts?

[Brian van den Broek]

On 28 October 2011 14:07, Marius Hofert  wrote:
> Hi,
>
> I downloaded and successfully installed the latest version org-mode (M-x 
> org-version shows 7.7). I was hoping to get org-contacts with it, too, but 
> when putting (require 'org-contacs) in .emacs, I obtain:
>
> Warning (initialization): An error occurred while loading 
> `/Users/mhofert/.emacs':
>
> File error: Cannot open load file, org-contacts
>
> To ensure normal operation, you should investigate and remove the
> cause of the error in your initialization file.  Start Emacs with
> the `--debug-init' option to view a complete error backtrace.
>
> Org-contacts is one of the contributions and can be found in org-7.7/contrib.
> How can I install this org-mode contribution (on Mac OS X 10.7.2 with GNU 
> Emacs 23.3 (9.0))?
>
> I installed the latest org-mode version by setting (in ./Makefile):
>
>  EMACS=/Applications/Emacs.app/Contents/MacOS//emacs
>  lispdir=/Applications/Emacs.app/Contents/Resources/lisp/
>  infodir=/Applications/Emacs.app/Contents/Resources/info
>
> I checked the contribution README, but that didn't tell  me how to install 
> org-mode ocntributions.
>
>
> Cheers,
>
> Marius
>


Marius,

Do you do what the fine manual suggests?:

If you plan to use code from the contrib subdirectory, do a similar
step for this directory:

 (setq load-path (cons "~/path/to/orgdir/contrib/lisp" load-path))

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

Best,

Brian vdB

[O] How to install contributions to org-mode such as org-contacts?

[Marius Hofert]

Hi,

I downloaded and successfully installed the latest version org-mode (M-x 
org-version shows 7.7). I was hoping to get org-contacts with it, too, but when 
putting (require 'org-contacs) in .emacs, I obtain:

Warning (initialization): An error occurred while loading 
`/Users/mhofert/.emacs':

File error: Cannot open load file, org-contacts

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the `--debug-init' option to view a complete error backtrace.

Org-contacts is one of the contributions and can be found in org-7.7/contrib.
How can I install this org-mode contribution (on Mac OS X 10.7.2 with GNU Emacs 
23.3 (9.0))?

I installed the latest org-mode version by setting (in ./Makefile):

 EMACS=/Applications/Emacs.app/Contents/MacOS//emacs
 lispdir=/Applications/Emacs.app/Contents/Resources/lisp/
 infodir=/Applications/Emacs.app/Contents/Resources/info

I checked the contribution README, but that didn't tell  me how to install 
org-mode ocntributions.


Cheers,

Marius

[O] Columns view for org-tags-view

[Ilya Zonov]

Hello!

First of all I want say thank you for great emacs mode, which I using for
planning my life and job. Org-mode is the best!

I used 7.7 version with some patches from development version. For example,
patchwhich
adds ability to cleanup items in agenda view (org-columns-cleanup-item
function).

I very like columns view, which I'm using for agenda views. So, I found that
%ITEM is not cleaned for agenda views are generated by org-tags-view. After
debuging and some investigation of org-tags-view code, I found that items in
agenda view generated by org-tags-view have no text-property
'org-complex-heading-regexp. In this case org-columns-cleanup-item does not
clean items.

Then I found that properties for item are coped in org-scan-tags function.
But org-complex-heading-regexp property is not coped here. I suggest to add
this property in this function. Please, could you check my correction? I
have no big experience in lisp codding. So, maybe this change have some
impact to other parts of org-mode. Here is little patch for version 7.7:

*** /usr/share/emacs/site-lisp/org-mode/org.el
--- Buffer org.el
***
*** 12514,12519 
--- 12514,12520 
'mouse-face 'highlight
'org-not-done-regexp org-not-done-regexp
'org-todo-regexp org-todo-regexp
+   'org-complex-heading-regexp org-complex-heading-regexp
'help-echo
(format "mouse-2 or RET jump to org file %s"
(abbreviate-file-name

-- 
Илья Зонов (Ilya Zonov) aka puzan
Nizhny Novgorod, Russia

Re: [O] Elisp programming style

[Štěpán Němec]

On Thu, 27 Oct 2011 20:03:22 +0200
Thorsten wrote:

> Hi List, 
> doing some Elisp programming (in an orgmode context) recently, the
> following question with regards to the 'accepted programming style' for
> Elisp concerned me:
>
> How independent and self-sustained should helper functions be? 
>
> I found some redundancy in elisp code, e.g. several (main and helper)
> functions that do exactly the same thing to extract the same specific
> args out of an argument list. My first reaction was, to factor out this
> extraction into the main function, and then call the helper functions
> from inside a (let ...) environment where the extracted args are stored
> in a local variable.
>
> But then I recognised, that the helper functions cannot be called
> independently anymore, but only make sense when called from this one
> main function with its local bindings.
>
> Is there a kind of convention in a case like this? Like: "Make every function,
> even a helper function, independent, and don't care about redundancy"?
> Just being curious

Too bad you didn't give any concrete examples.

In general, if the helper function is only used in a single place and
isn't likely to be more generally useful, there might be no reason for
it to be a standalone function at all (other than modular programming,
which is always a good idea IMO).

OTOH, if the helper function _is_ standalone and used in multiple
places, then there is no "redundancy", so I'm really not sure what you
mean.

If I understand you correctly, you find multiple pairs of main and
helper functions, where the helper does very similar things. In that
case the right thing would seem to be to abstract all the helpers into a
single helper and use that in all the main functions.

[To clarify, this all is just an opinion of an interested Emacs and Org
user who often pulls his hair when trying to make use of/fix bugs in
existing code and bumping into lacks in modular design. The maintainers
will perhaps provide more authoritative guidelines.]

-- 
Štěpán

Re: [O] Makefile restructuring

[Achim Gratz]

Is someone still tracks this thread:

I'm still working on the fork, recent changes have been the elimination
of the dependencies.  I've found no simple way to automatically generate
them and even then it would have been really difficult to keep Emacs
from picking up stale byte-compiled files.  While I've developed a way
that allowed to remove all .elc files that a new compile would
re-create, I deemed it far too hacky to go live.  Instead a ``make
clean´´ is now implicit with ``make compile´´ so that there should be no
problems anymore that are caused by the order of byte-compilation.

As discussed in another thread, the version from git-describe is now
also recorded into the info documentation.


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

[O] [PATCH] Adding features to contrib/lisp/org-collector.el (propview)

[Jonathan BISSON]

Hi there,


I did a small patch for org-collector.

Here are the changes :
- Adding a :colnames property, allowing to give the column names
(instead of displaying the function used to populate the table)
- Adding a :noquote property, allowing to remove the double quotes
around strings

I hope some of you would find it useful.

121a122,123
>   (noquote (plist-get params :noquote))
>   (colnames (plist-get params :colnames))
132a135
> (setq stringformat (if noquote "%s" "%S"))
134c137,138
<  (org-propview-collect cols conds match scope inherit)))
---
>  (org-propview-collect cols stringformat conds match scope
inherit
>(if colnames colnames cols)) 
> stringformat))
170c174
< (defun org-propview-collect (cols &optional conds match scope inherit)
---
> (defun org-propview-collect (cols stringformat &optional conds match
scope inherit colnames)
194,195c198,199
<   (mapcar (lambda (el) (format "%S" el)) cols) ;; output headers
<   'hline) ;; 
---
>   (if colnames colnames (mapcar (lambda (el) (format stringformat
el)) cols))
>'hline) ;; 
214c218
< (defun org-propview-to-table (results)
---
> (defun org-propview-to-table (results stringformat)
221c225
<   (mapcar (lambda (el) (format "%S" el)) row)))
---
>   (mapcar (lambda (el) (format stringformat el)) row)))



signature.asc
Description: OpenPGP digital signature

Re: [O] "git describe" in version of info file with "make info_git_describe"

[Achim Gratz]

Michael Brand  writes:
> If set-version.pl would be obsolete my patch would be much shorter and
> I would use something even more portable than perl to change the
> version in /tmp/org.texi like the POSIX/SUS ed command, used inline in
> the Makefile. Would you agree?

I don't know if it is still used by the maintainers for preparing a
release.  I do know that there are no version numbers in the source
files any more, so that part of set-version.pl surely is obsolete.  The
other parts may become obsolete if whatever is still in used can be
moved to make.  I've already started to reduce the reliance on perl in
my branch, switching to sed where possible.

> I can remember some discussion but haven't realized that the outcome
> is a pending merge. Hence I declare version 2 of my patch as "Changes
> Requested" on patchwork (can't change this myself) and will rebase it
> against your changes.

Again I don't know if or when this gets merged.  I've already used up my
TINYCHANGEs and hit an impasse with the FSF papers that I don't know how
to resolve... :-(  Then again, the build system doesn't really become
part of Emacs, but it's up to the maintainers to decide.

> Yes, good point. I was aware of that and therefore for the target
> "info-vg", doc/org.texi is copied to /tmp/org.texi, altered only there
> and makeinfo reads from there.

I'd much prefer to inject the version in a different way, not making an
altered copy that the build works from.  The result is the same, but it
doesn't feel OK... so probably the solution should be to get the version
injected via some @set in an @include file (that's the recommended way
from the Texinfo perspective, anyway) that is produced by make whenever
the source file changes.

> And I _added_ the target "info-vg" because implementing the same
> functionality in the target "info" itself, by either adding an
> auto-detect whether git describe is available (like org-version does)
> or using org-version itself, is not an option. One still needs to have
> the unchanged target "info" to build a release with the info version
> not possibly influenced by git describe.

I posit that if it's worth to have that (I'd say yes), ``make info´´
should do that, in a way that is compatible with version control.
Anyway, I've implemented the requested functionality into my Makefile
fork, please test.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [O] "Clocktable summary at ..." line not showing up right in export

[Giovanni Ridolfi]

Herbert Sitz  writes:

Hi, Herbert,
> I'm exporting 

exporting-to-what ?

> a file with a clocktable and the first line of the Clocktable
> shows up with no date or time info, just:
>
> "Clock summary at" [followed by nothing]
> | Headline|   Time |
> |-+|
> | *Total time*| *5:11* |
> |-+|
> | DONE Tasks and States   |   1:01 |
> | FIXME Custom agenda views   |   0:01 |

Well, here, 
the HTML, ascii, LaTeX  export of the *subtree*

work as expected,

Org-mode version 7.7 679a0e1fe93d630820185f931087328d32e81077
GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO

> I'm using Org 7.4 and Emacs 23.1.

I suggest you to update your org, if the error persists, perhaps, even
your Emacs. 

hth
Giovanni

Re: [O] Feature Request: Disable auto-insert-mode exporting

[Carsten Dominik]

On 28.10.2011, at 06:49, Darlan Cavalcante Moreira wrote:

> 
> Thanks Nick,
> 
> You right, the master file question comes from auctex. But with your code
> it's simple to add the relevant variable to solve the issue. The final
> function is
> --8<---cut here---start->8---
> (defadvice org-export (around org-export-no-auto-insert)
>  (let ((auto-insert nil)
>(TeX-master t)
>)
>ad-do-it))


Ahh, that has been bothering me for many years, thanks for this solution.
I have made this behavior (as well as turning off auto-insert) now
standard in Org-mode, so the advice will no longer be needed.

Or, can anyone come up with a reason why the AUCTeX query or auto-insert
stuff could be useful when creating new files during Org-mode export?

- Carsten


> 
> (ad-activate 'org-export)
> --8<---cut here---end--->8---
> 
> --
> Darlan
> 
> At Thu, 27 Oct 2011 17:03:55 -0400,
> Nick Dokos  wrote:
>> 
>> Darlan Cavalcante Moreira  wrote:
>> 
>>> 
>>> I consider auto-insert-mode to be a very useful feature in Emacs and it
>>> works great in most situations, except when exporting an org-mode buffer.
>>> 
>>> If I export to PDF or HTML, for instance, then org-mode creates a TeX or an
>>> HTML buffer and auto-insert kicks-in in both cases (asking for the title in
>>> the HTML buffer, or the master file in the TeX buffer). Whatever I write
>>> will be overwritten by the org-mode exporter and the file exports just
>>> fine, but this interruption is annoying.
>>> 
>> 
>> I don't think the master file question comes from auto-insert - I believe
>> it comes from auctex. In particular, I get the question but I don't have
>> auto-insert enabled for latex.
>> 
>>> I suppose I could create a function that disable auto-insert-mode, call
>>> org-export and then re-enable auto-insert-mode, but maybe this should be
>>> the default behaviour of org-mode export. Does this make sense?
>>> 
>> 
>> You can advise org-export:
>> 
>> (defadvice org-export (around org-export-no-auto-insert)
>>  (let ((auto-insert nil))
>>ad-do-it))
>> 
>> (ad-activate 'org-export)
>> 
>> should do it (untested).
>> 
>> Nick
> 

Re: [O] [ANN][RFC] org-odt.texi/org-odt.pdf preview (was Re: Org-odt table format)

[Christian Moe]

Hi,

Great, I'll just wait for your revised draft so we don't get versions 
mixed up.


Yours,
Christian

On 10/28/11 6:19 AM, Jambunathan K wrote:

I will work on your suggestions and circulate a
revised draft shortly.

Once an initial org.texi gets in to the repo, improving it would be a
breeze.