[O] org-html-publish-to-html fails to recognize BEGIN_EXAMPLE/END_EXAMPLE blocks when exporting an example containing org-mode heading

[Iannis Zannos]

Hello,

when trying to export as html an example which contains org-mode headings,
the example is not "quoted" in mono-space as it should be. Example:

*1. Failing example: *



This is a test of publishing an example which contains org mode code in
html:

#+BEGIN_EXAMPLE
* test
#+END_EXAMPLE

End of test.



*2. Workaround: *

This works as expected, but only because the * headline is indented by 1
character:



This is a test of publishing an example which contains org mode code in
html:

#+BEGIN_EXAMPLE
 * test
#+END_EXAMPLE

End of test.



I used (meta-x) org-html-export-to-html to do the export.
Same happens with org-publish.

I am running following emacs version:
GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of
2013-03-13 on bob.porkrind.org

on MacOS X 10.8.5

with org-mode version:
Org-mode version 8.0.7 (8.0.7-6-g13cb28-elpa @
/Users/iani2/.emacs.d/elpa/org-20130812/)

Is this a bug? Any suggestions?

Iannis Zannos

[O] #+END_SRC and recent pull

[Noorul Islam Kamal Malmiyoda]

Hello all,

I pulled in latest changes from master and the following snippet is
not getting tangled.

#+begin_src emacs-lisp
(message "This is a test")
#+end_src emacs-lisp

Yes, the documentation has plain #+end_src, but somehow the above
snippet was working earlier.

Sending this mail out, just in case this is useful to someone else.

Does the parser should really care about what is next to #+end_src ?

Thanks and Regards
Noorul

Re: [O] [BUG] Tags matching

[Noorul Islam K M]

Carsten Dominik  writes:

> On 26.9.2013, at 05:50, Noorul Islam K M  wrote:
>
>> 
>> Hello all,
>> 
>> I use Bernt Hansen's custom Agenda view. Here is a snippet from that
>> 
>>(tags-todo "-CANCELLED/+WAITING/!"
>
> There should be no slash before the +WAITING.  It is also not present in 
> Bernt's text.
>
> Does that fix it?
>

Oh yes! Thank you!

Thanks and Regards
Noorul

> - Carsten
>
>>   ((org-agenda-overriding-header "Waiting and 
>> Postponed
>> Tasks")
>>(org-agenda-skip-function 'bh/skip-stuck-projects)
>>(org-tags-match-list-sublevels nil)
>>(org-agenda-todo-ignore-scheduled 'future)
>>(org-agenda-todo-ignore-deadlines 'future)))
>> 
>> This stopped working with current master. I nailed down the commit
>> (3e99e9298c534f19bd19f37c196b0850e2c99ca0) which is affecting the
>> original behavior. With this commit it lists all my todo items under
>> this heading.
>> 
>> Thanks and Regards
>> Noorul
>> 

Re: [O] [BUG] Tags matching

[Carsten Dominik]

On 26.9.2013, at 05:50, Noorul Islam K M  wrote:

> 
> Hello all,
> 
> I use Bernt Hansen's custom Agenda view. Here is a snippet from that
> 
>(tags-todo "-CANCELLED/+WAITING/!"

There should be no slash before the +WAITING.  It is also not present in 
Bernt's text.

Does that fix it?

- Carsten

>   ((org-agenda-overriding-header "Waiting and 
> Postponed
> Tasks")
>(org-agenda-skip-function 'bh/skip-stuck-projects)
>(org-tags-match-list-sublevels nil)
>(org-agenda-todo-ignore-scheduled 'future)
>(org-agenda-todo-ignore-deadlines 'future)))
> 
> This stopped working with current master. I nailed down the commit
> (3e99e9298c534f19bd19f37c196b0850e2c99ca0) which is affecting the
> original behavior. With this commit it lists all my todo items under
> this heading.
> 
> Thanks and Regards
> Noorul
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

[O] [BUG] Tags matching

[Noorul Islam K M]

Hello all,

I use Bernt Hansen's custom Agenda view. Here is a snippet from that

(tags-todo "-CANCELLED/+WAITING/!"
   ((org-agenda-overriding-header "Waiting and Postponed
Tasks")
(org-agenda-skip-function 'bh/skip-stuck-projects)
(org-tags-match-list-sublevels nil)
(org-agenda-todo-ignore-scheduled 'future)
(org-agenda-todo-ignore-deadlines 'future)))

This stopped working with current master. I nailed down the commit
(3e99e9298c534f19bd19f37c196b0850e2c99ca0) which is affecting the
original behavior. With this commit it lists all my todo items under
this heading.

Thanks and Regards
Noorul

[O] Elpa color-theme with emacs24

[Rene]

I just tried out color-theme with emacs24.

It seems the code on http://orgmode.org/worg/org-color-themes.html is not
quite compatible with elpa packages.

Here is what I used instead.

;---
; To easily cycle between different colour schemes using the F4 key
(require 'color-theme)
(require 'cyberpunk-theme)
(require 'leuven-theme)
(require 'tangotango-theme)
(require 'zenburn-theme)
(setq color-theme-is-global t)

(setq my-color-themes (list
   'cyberpunk
   'leuven
   'zenburn
   'tangotango
   ))

(defun my-theme-set-default () ; Set the first row
  (interactive)
  (setq theme-current my-color-themes)
  (load-theme  (car theme-current) t))

(defun my-describe-theme () ; Show the current theme
  (interactive)
  (message "My color theme: %s" (car theme-current)))

(defun my-theme-cycle (); Set the next theme
  (interactive)
  (setq theme-current (cdr theme-current))
  (if (null theme-current)
  (setq theme-current my-color-themes))
  (load-theme  (car theme-current) t)
  (message "My color theme: %S" (car theme-current)))

(setq theme-current my-color-themes)
(setq color-theme-is-global nil) ; Initialization
(my-theme-set-default)
(global-set-key [f4] 'my-theme-cycle)
;

--
Rene

Re: [O] build errors on os x

[Skip Collins]

The problem persists. Can anyone else confirm? Perhaps this should be
added to the bug tracker file. For the record, my local.mk file is:
EMACS = /Applications/Emacs.app/Contents/MacOS/Emacs
prefix = /usr/local/share

On Tue, Sep 24, 2013 at 11:11 AM, Skip Collins  wrote:
>
> For the last few days, building org with make up2 results in the
> following failed tests with Emacs for Mac OS X 24.3.1:
>
> Ran 456 tests, 448 results as expected, 8 unexpected (2013-09-24 
> 10:59:21-0400)
> 5 expected failures
>
> 8 unexpected results:
>FAILED  test-ob/org-babel-remove-result--results-code
>FAILED  test-ob/org-babel-remove-result--results-default
>FAILED  test-ob/org-babel-remove-result--results-html
>FAILED  test-ob/org-babel-remove-result--results-latex
>FAILED  test-ob/org-babel-remove-result--results-list
>FAILED  test-ob/org-babel-remove-result--results-org
>FAILED  test-ob/org-babel-remove-result--results-pp
>FAILED  test-ob/org-babel-remove-result--results-wrap

Re: [O] Org mode issue tracker

[Suvayu Ali]

Hello Michael,

This is the general structure I'm proposing:

  * TODO Subject  :emacs_ver:org_ver:org_module:
:PROPERTIES:
:DEBGUGS_ID:  
:REPORTER:
:CC_EMAIL:
:END:

I elaborate the ideas below.

On Wed, Sep 25, 2013 at 08:56:50PM +0200, Michael Albinus wrote:
> 
> Let's check it with an example. For bug 15081, debbugs-gnu returns the
> following list:
> 
> ((source . "unknown")
>  (found_versions "24.3")

Emacs version ends up as a tag:

* TODO  .   :24.3:

>  (done)
>  (blocks)
>  (date . 1376383861)

* TODO  .   :24.3:
  <2013-08-13 Tue>

>  (fixed)
>  (fixed_versions)
>  (mergedwith)
>  (found
>   (item
>(key . 24.3)
>(value)))
>  (unarchived)
>  (blockedby)
>  (keywords)
>  (summary)
>  (msgid . "<877gfqkm9t@gmail.com>")

An added bonus idea: Gmane has this amazing feature where you can link
to a message using it's message id.  So a property like: GMANE_URL would
be awesome.

* TODO  .   :24.3:
  :PROPERTIES:
  :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com
  :END:
  <2013-08-13 Tue>

>  (id . 15081)

* TODO  .   :24.3:
  :PROPERTIES:
  :DEBGUGS_ID:  15081
  :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com
  :END:
  <2013-08-13 Tue>

It would be cool if you could provide a function that uses browse-url to
direct you to the webpage using DEBGUGS_ID:

  

>  (forwarded)
>  (severity . "normal")
>  (owner)
>  (log_modified . 1376383862)
>  (location . "db-h")
>  (subject . "24.3; org-crypt: Making epg-context local to  *epg* while 
> let-bound!")

* TODO Making epg-context local to  *epg* while let-bound! :24.3:org_crypt:
  :PROPERTIES:
  :DEBGUGS_ID:   15081
  :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com
  :END:
  <2013-08-13 Tue>

As you see above, it would be great if we could simplify the suject and
tag the org-module involved (note hyphens are not allowed, they need to
be transformed to underscore).

>  (originator . "Thierry Volpiatto ")

* TODO Making epg-context local to  *epg* while let-bound! :24.3:org_crypt:
  :PROPERTIES:
  :DEBGUGS_ID:   15081
  :REPORTER: Thierry Volpiatto 
  :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com
  :END:
  <2013-08-13 Tue>

>  (last_modified . 1376408720)

Maybe this should go into a property called: LAST_MODIFIED.

>  (pending . "pending")

And this should finally decide the TODO state.  For the moment a
reasonable mapping would be "pending" -> "TODO".  But would be good to
have support for "DONE", "WIP", or similar (I'm not familiar with all
the debbug states :-p)

>  (affects)
>  (archived)
>  (tags)
>  (package "emacs" "org-mode")

I guess this is how you filter out org-mode bugs from the rest.

>  (fixed_date)
>  (found_date)
>  (bug_num . 15081))
> 
> The keys shall be self-explaining. How would a TODO item look like?
> Note, that these metadata do not contain the corresponding messages
> yet. debbugs-gnu could retrieve them in a second run; the TODO item
> shall offer a link to them, inline.

So finally I propose the following for this particular bug.

* TODO Making epg-context local to  *epg* while let-bound! :24.3:org_crypt:
  :PROPERTIES:
  :DEBGUGS_ID:   15081
  :REPORTER: Thierry Volpiatto 
  :GMANE_URL:http://mid.gmane.org/877gfqkm9t@gmail.com
  :END:
 152 <2013-08-13 Tue>

However in this example there were no "interested parties".  If you take
this (non org-mode) bug as an example:

  ,

the CC_EMAIL property would be: "Eli Zaretskii , Gregor
Zattler , , Paul Eggert
", and all the contributors to bug 15222 (that would
be me :-p, Suvayu Ali ).


What do others think?  Is it a good start?  Overall this looks very
promising, I am excited :).

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

[O] example filter for code blocks?

[John Kitchin]

Hi everyone,

I have an idea for putting links in a pdf that would open python code
blocks in an editor. To do that, I need to modify what happens when an
org-file is published to latex.

Essentially I want it to do exactly what it already does in terms of
running pygments, and making nicely formatted and syntax highlighted code
blocks and output.

After that though, I want to tangle the code block to a file in a
directory, and insert a new link after the rendered code block. I would
prefer not to have to put :tangle headings in each code block because there
are many (e.g. hundreds) of them in course notes. It would be sufficient if
they were just sequentially numbered as dir/1.py, dir/2.py, etc... and it
is fine if these get overwritten on each export.

the link that would go after the code block in the latex export would be
something like:
\LaunchPython{dir/1.py}{Open code}

Then clicking on it would open dir/1.py in whatever editor your system is
configured for. \LaunchPython is a newcommand I have defined that works
already.

It seems like the new export engine should make this easy to do, but I am
not sure where to start. Could anyone point me to a starting place? Thanks!


John

---
John Kitchin
Associate Professor
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu

Re: [O] Org mode issue tracker

[Bastien]

Hi Sébastien,

"Sebastien Vauban" 
writes:

> Please note that the "Show Org source" button still shows the old
> Org file.

Indeed -- the sources for all Worg files were not properly updated,
I just fixed this.  Thanks!

-- 
 Bastien

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Nicolas Goaziou]

Carsten Dominik  writes:

> Not really.  It would simplify processing to have the list instead
> of a string, but indeed, a filter can accomplish all of it.

Here is a first patch. It doesn't handle export back-ends in contrib.


Regards,

-- 
Nicolas Goaziou
>From c48974d10e0d57b6332fcfed384a49ee530ea04a Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Wed, 25 Sep 2013 21:27:29 +0200
Subject: [PATCH] ox: Add a defcustom to export properties drawers

* lisp/ox.el (org-export-with-drawers): Improve docstring.
(org-export-with-properties): New variable
(org-export--skip-p): Handle new variable.
(org-export-options-alist): Install new variable.
* lisp/ox-ascii.el (org-ascii-node-property,
  org-ascii-property-drawer): New functions.
* lisp/ox-html.el (org-html-node-property): New function.
(org-html-property-drawer): Export property drawers as "pre" blocks.
* lisp/ox-latex.el (org-latex-property-drawer,
  org-latex-node-property): New functions.
* lisp/ox-man.el (org-man-node-property, org-man-property-drawer): New
  functions.
* lisp/ox-md.el (org-md-node-property, org-md-property-drawer): New
  functions.
* lisp/ox-odt.el (org-odt-node-property): New function.
(org-odt-property-drawer): Export property drawers as fixed width
blocks.
* lisp/ox-texinfo.el (org-texinfo-node-property): New function.
(org-texinfo-property-drawer): Export property drawers as verbatim
blocks.
* testing/lisp/test-ox.el: Add tests.
---
 lisp/ox-ascii.el| 23 +++
 lisp/ox-html.el | 21 -
 lisp/ox-latex.el| 25 -
 lisp/ox-man.el  | 19 ++-
 lisp/ox-md.el   | 24 
 lisp/ox-odt.el  | 23 ++-
 lisp/ox-texinfo.el  | 21 -
 lisp/ox.el  | 28 +---
 testing/lisp/test-ox.el | 19 +++
 9 files changed, 183 insertions(+), 20 deletions(-)

diff --git a/lisp/ox-ascii.el b/lisp/ox-ascii.el
index 74a7c64..e0a3fa9 100644
--- a/lisp/ox-ascii.el
+++ b/lisp/ox-ascii.el
@@ -81,10 +81,12 @@
 (latex-fragment . org-ascii-latex-fragment)
 (line-break . org-ascii-line-break)
 (link . org-ascii-link)
+(node-property . org-ascii-node-property)
 (paragraph . org-ascii-paragraph)
 (plain-list . org-ascii-plain-list)
 (plain-text . org-ascii-plain-text)
 (planning . org-ascii-planning)
+(property-drawer . org-ascii-property-drawer)
 (quote-block . org-ascii-quote-block)
 (quote-section . org-ascii-quote-section)
 (radio-target . org-ascii-radio-target)
@@ -1440,6 +1442,18 @@ INFO is a plist holding contextual information."
 	 (unless org-ascii-links-to-notes (format " (%s)" raw-link
 
 
+ Node Properties
+
+(defun org-ascii-node-property (node-property contents info)
+  "Transcode a NODE-PROPERTY element from Org to ASCII.
+CONTENTS is nil.  INFO is a plist holding contextual
+information."
+  (format "%s:%s"
+  (org-element-property :key node-property)
+  (let ((value (org-element-property :value node-property)))
+(if value (concat " " value) ""
+
+
  Paragraph
 
 (defun org-ascii-paragraph (paragraph contents info)
@@ -1509,6 +1523,15 @@ channel."
" "))
 
 
+ Property Drawer
+
+(defun org-ascii-property-drawer (property-drawer contents info)
+  "Transcode a PROPERTY-DRAWER element from Org to ASCII.
+CONTENTS holds the contents of the drawer.  INFO is a plist
+holding contextual information."
+  (org-string-nw-p contents))
+
+
  Quote Block
 
 (defun org-ascii-quote-block (quote-block contents info)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 14b31b2..66862bc 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -76,6 +76,7 @@
 (latex-fragment . org-html-latex-fragment)
 (line-break . org-html-line-break)
 (link . org-html-link)
+(node-property . org-html-node-property)
 (paragraph . org-html-paragraph)
 (plain-list . org-html-plain-list)
 (plain-text . org-html-plain-text)
@@ -2782,6 +2783,17 @@ INFO is a plist holding contextual information.  See
  ;; No path, only description.  Try to do something useful.
  (t (format "%s" desc)
 
+ Node Property
+
+(defun org-html-node-property (node-property contents info)
+  "Transcode a NODE-PROPERTY element from Org to HTML.
+CONTENTS is nil.  INFO is a plist holding contextual
+information."
+  (format "%s:%s"
+  (org-element-property :key node-property)
+  (let ((value (org-element-property :value node-property)))
+(if value (concat " " value) ""
+
  Paragraph
 
 (defun org-html-paragraph (paragraph contents info)
@@ -2930,11 +2942,10 @@ channel."
 
 (defun org-html-property-drawer (property-drawer contents info)
   "Transcode a PROPERTY-DRAWER element from Org to HTML.
-CONTENTS is nil.  INFO is a plist holding contextual
-information."
-  ;; The property drawer isn't exported but we 

Re: [O] org mode R remote code evaluation

[Alexander Vorobiev]

Michael,

I found that the patch doesn't work for sql code blocks. Here is an example

* this works
#+BEGIN_SRC sh :results output :dir /grid:
  ls
#+END_SRC

* this doesn't work
#+BEGIN_SRC sql :engine postgresql :dir /grid: :results output
  select 1+2 as three;
#+END_SRC

and here is what appears in *Messages*:

executing Sh code block...
Tramp: Encoding region using function `base64-encode-region'...done
Tramp: Decoding region into remote file
/plinkx:grid:/tmp/ob-input-7928Z4Q...done
Tramp: Encoding region using function `base64-encode-region'...done
Tramp: Decoding region into remote file
/plinkx:grid:/tmp/ob-error-7928zMd...done
Tramp: Encoding region using function `base64-encode-region'...done
Tramp: Decoding region into remote file
/plinkx:grid:/tmp/ob-input-7928Z4Q...done
Wrote /plinkx:grid:/tmp/ob-input-7928Z4Q
Code block evaluation complete.
executing Sql code block...
Tramp: Encoding region using function `base64-encode-region'...done
Tramp: Decoding region into remote file
/plinkx:grid:/tmp/sql-in-7928arv...done
Tramp: Encoding region using function `base64-encode-region'...done
Tramp: Decoding region into remote file
/plinkx:grid:/tmp/sql-out-7928Z_E...done
Tramp: Encoding region using function `base64-encode-region'...done
Tramp: Decoding region into remote file
/plinkx:grid:/tmp/sql-in-7928arv...done
psql -A  -F " "  -f "c:/tmp/sql-in-7928arv" -o "c:/tmp/sql-out-7928Z_E"
-f c:/tmp/sql-in-7928arv -o c:/tmp/sql-out-7928Z_E
No such file or directory 'c:/tmp/sql-in-7928arv'
Tramp: Inserting `/plinkx:grid:/tmp/sql-out-7928Z_E'...
Tramp: Encoding remote file /plinkx:grid:/tmp/sql-out-7928Z_E...done
Tramp: Decoding remote file /plinkx:grid:/tmp/sql-out-7928Z_E with function
base64-decode-region...
Wrote c:/Users/avorobi/AppData/Local/Temp/tramp.7928AeX
Tramp: Decoding remote file /plinkx:grid:/tmp/sql-out-7928Z_E with function
base64-decode-region...done
Tramp: Inserting `/plinkx:grid:/tmp/sql-out-7928Z_E'...done

So shell commands work but the arguments passed to psql have "c:" at the
beginning.

Thanks
Alex



On Wed, Sep 25, 2013 at 2:03 PM, Michael Albinus wrote:

> Eric Schulte  writes:
>
> > I'd rather not hard-code the value of "/tmp/".  Perhaps you could rework
> > the patch so that it introduces a new customizable variable (including a
> > documentation string) so that users can set the value for their system.
>
> Will do, tomorrow. I would even prefer a more general solution, a new
> function which returns a ("the") temp directory on a remote host. This
> would be useful also outside org-mode. But this would require changes in
> Emacs/Tramp, which won't be applicable for org immediately (backwards
> compatibility, and alike).
>
> > If you can keep the patch under 15LOC we can include it w/o requiring
> > FSF copyright assignment, otherwise see [1] for contribution details.
>
> No problem. As Tramp maintainer, I have signed the FSF papers for Emacs
> 10+ years ago. This shall be valid also for org patches.
>
> > Thanks,
>
> Best regards, Michael.
>

[O] [PATCH] Display a count of items next to each list (or block)

[Sebastien Vauban]

Hello,

In order to make Org much nicer to use, I felt we missed a count of items next
to the lists (or blocks, for multi-block agenda views). Here is a patch to add
this, depending on the new variable `org-agenda-display-count-of-items'
(enabled by default).

The count of items must be updated when you apply tag filtering on lists. The
patch does it as well.

Please enjoy (or be scared by the real number of items you have on your TODO
lists)!!

Best regards,
  Seb

From: "Sebastien Vauban" 
Date: Wed, 25 Sep 2013 21:56:01 +0200
Subject: [PATCH] Display a count of items next to each list (or block)

* org-agenda.el (org-agenda-display-count-of-items): New variable.
(org-agenda-insert-count-of-items)
(org-agenda-count-visible-lines-block)
(org-agenda-remove-filtered-count): New helper functions.
(org-search-view, org-todo-list, org-tags-view): Add count of
items.
(org-agenda-filter-by-tag, org-agenda-filter-apply): Add or
remove filtered count of items.
(org-agenda-goto-block-beginning): Fix problems for position
of point.
(org-agenda-goto-next-block): New command.

---
 lisp/org-agenda.el |   89 ---
 1 files changed, 83 insertions(+), 6 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index c48da91..336991f 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4652,6 +4652,8 @@ in `org-agenda-text-search-extra-files'."
   (when rtnall
(insert (org-agenda-finalize-entries rtnall 'search) "\n"))
   (goto-char (point-min))
+  (when org-agenda-display-count-of-items
+   (org-agenda-insert-count-of-items rtnall))
   (or org-agenda-multi (org-agenda-fit-window-to-buffer))
   (add-text-properties (point-min) (point-max)
   `(org-agenda-type search
@@ -4663,6 +4665,46 @@ in `org-agenda-text-search-extra-files'."
 
 ;;; Agenda TODO list
 
+(defvar org-agenda-display-count-of-items t
+  "Display count of items next to each list.")
+
+(defun org-agenda-insert-count-of-items (count)
+  "Insert count of items at the end of current line."
+  (save-excursion
+(end-of-line)
+(insert " "
+   (org-add-props (format "(%s)" (length rtnall)) nil
+ 'face 'org-agenda-block-count
+
+(defun org-agenda-count-visible-lines-block ()
+  "Count the number of items visible in the current block."
+  (interactive)
+  (let ((count 0))
+(save-excursion
+  (org-agenda-goto-block-beginning)
+  (while (equal (get-char-property (point) 'face) 'org-agenda-structure) ; 
header line(s)
+   (forward-visible-line 1))
+  (while (or (equal (get-char-property (point) 'face) 'default)
+(equal (get-char-property (point) 'type) "tagsmatch")
+(equal (get-char-property (point) 'type) "todo")) ; entry line
+   (unless (get-char-property (point) 'invisible)
+ (setq count (1+ count)))
+   (forward-visible-line 1))
+  count)))
+
+(defun org-agenda-remove-filtered-count ()
+  "Remove `X/' from filtered count string `(X/Y)'.
+
+Leaves point at total count."
+  (org-agenda-goto-block-beginning)
+  (while (not (equal (get-text-property (point) 'face)
+'org-agenda-block-count))
+(forward-char))
+  (forward-char); for "("
+  (when (looking-at "[0-9]*/")
+(kill-word 1)   ; digits
+(delete-char 1)))   ; slash
+
 (defun org-agenda-propertize-selected-todo-keywords (keywords)
   "Use `org-todo-keyword-faces' for the selected todo KEYWORDS."
   (concat
@@ -4753,6 +4795,8 @@ for a keyword.  A numeric prefix directly selects the Nth 
keyword in
   (when rtnall
(insert (org-agenda-finalize-entries rtnall 'todo) "\n"))
   (goto-char (point-min))
+  (when org-agenda-display-count-of-items
+   (org-agenda-insert-count-of-items rtnall))
   (or org-agenda-multi (org-agenda-fit-window-to-buffer))
   (add-text-properties (point-min) (point-max)
   `(org-agenda-type todo
@@ -4840,6 +4884,8 @@ The prefix arg TODO-ONLY limits the search to TODO 
entries."
   (when rtnall
(insert (org-agenda-finalize-entries rtnall 'tags) "\n"))
   (goto-char (point-min))
+  (when org-agenda-display-count-of-items
+   (org-agenda-insert-count-of-items rtnall))
   (or org-agenda-multi (org-agenda-fit-window-to-buffer))
   (add-text-properties (point-min) (point-max)
   `(org-agenda-type tags
@@ -7448,6 +7494,13 @@ to switch to narrowing."
   (org-agenda-filter-show-all-tag)
   (when (get 'org-agenda-tag-filter :preset-filter)
(org-agenda-filter-apply org-agenda-tag-filter 'tag))
+  ;; count of items
+  (when org-agenda-display-count-of-items
+   (save-excursion
+ (goto-char (point-min)) ; beginning of first block
+ (while (or (equal (point) (point-min))

Re: [O] using gnuplot's "splot" and "every" commands on org-mode table data

[Paul Stansell]

> I agree that it is easier and more clear to include "set datafile
> missing..." in the body of a gnuplot code block.  I *do* think that the
> :missing header argument has value specifically as a way to replace
> missing values in the original table data.
>
> I've changed the behavior of the :missing header argument so that it
> *only* replaces missing values in table data and does not add a "set
> datafile missing..." line to the code block.

If I understand you correctly I think that sounds like a good
solution.  As I understand it, your recent changes mean that if the
:missing header is not used the table data will be exported "as is",
ie, with no changes, replacements or additions to any of the
characters in the table cells; however, if the ':missing "?"' header
is used any empty table cells will be exported as ? (with no quotes)
and one needs to explicitly add

  set datafile missing "?"

to the code block.  In fact, it's not actually necessary to add this
line to the code block as gnuplot will treat the non-parsible "?"
string as missing data without the line.

Regards,

Paul

Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer

[Andreas Leha]

On the ess list (emacs.ess.general) there has been the
announcement [fn:2] of polymode [fn:1] recently, which is going in this
direction.

Since my elisp knowledge is limited to the least, this comment might be
irrelevant here, in which case please ignore it.

Regards,
Andreas



Footnotes:

[fn:1] https://github.com/vitoshka/polymode

[fn:2] http://comments.gmane.org/gmane.emacs.ess.general/6994

Re: [O] Spurious exporting of text before first header

[François Pinard]

Nicolas Goaziou  writes:

> François Pinard  writes:

>> The spirit behind :export: is [...]

> I agree, this is a misfeature. This should be fixed in master.  Thank
> you for bringing it out.

Thanks as well. :-)

François

Re: [O] org mode R remote code evaluation

[Michael Albinus]

Eric Schulte  writes:

> I'd rather not hard-code the value of "/tmp/".  Perhaps you could rework
> the patch so that it introduces a new customizable variable (including a
> documentation string) so that users can set the value for their system.

Will do, tomorrow. I would even prefer a more general solution, a new
function which returns a ("the") temp directory on a remote host. This
would be useful also outside org-mode. But this would require changes in
Emacs/Tramp, which won't be applicable for org immediately (backwards
compatibility, and alike).

> If you can keep the patch under 15LOC we can include it w/o requiring
> FSF copyright assignment, otherwise see [1] for contribution details.

No problem. As Tramp maintainer, I have signed the FSF papers for Emacs
10+ years ago. This shall be valid also for org patches.

> Thanks,

Best regards, Michael.

Re: [O] Spurious exporting of text before first header

[François Pinard]

"Sebastien Vauban" 
writes:

> If you like text without initial heading in the exported file, but don't mind
> adding an heading in the Org buffer, you could add this:

> * Initial text :ignoreheading:

> and get what you want in the exported file.

As I had to move on this, I just added such headings everywhere.  Sigh! :-)

François

Re: [O] Org mode issue tracker

[Michael Albinus]

"Loyall, David"  writes:

>> (I'm not so experienced with org-mode, so I would need at least some
>> assistance how such a TODO item should look like)
>
> A 'headline' is a 'TODO item' if-and-only-if it contains one of the
> TODO Keywords in the appropriate position.
>
> See: http://orgmode.org/worg/dev/org-syntax.html
>
> While you're in that document, have a look at the various structures
> that can live inside a headline (for example, timestamps).

Thanks. I've contacted already the org info pages, in order to get an
idea what's possible. But a general doc is one thing, a mapping of a
debbugs record onto a TODO entry is another one.

Let's check it with an example. For bug 15081, debbugs-gnu returns the
following list:

((source . "unknown")
 (found_versions "24.3")
 (done)
 (blocks)
 (date . 1376383861)
 (fixed)
 (fixed_versions)
 (mergedwith)
 (found
  (item
   (key . 24.3)
   (value)))
 (unarchived)
 (blockedby)
 (keywords)
 (summary)
 (msgid . "<877gfqkm9t@gmail.com>")
 (id . 15081)
 (forwarded)
 (severity . "normal")
 (owner)
 (log_modified . 1376383862)
 (location . "db-h")
 (subject . "24.3; org-crypt: Making epg-context local to  *epg* while 
let-bound!")
 (originator . "Thierry Volpiatto ")
 (last_modified . 1376408720)
 (pending . "pending")
 (affects)
 (archived)
 (tags)
 (package "emacs" "org-mode")
 (fixed_date)
 (found_date)
 (bug_num . 15081))

The keys shall be self-explaining. How would a TODO item look like?
Note, that these metadata do not contain the corresponding messages
yet. debbugs-gnu could retrieve them in a second run; the TODO item
shall offer a link to them, inline.

> Thank you,
> --Dave

Best regards, Michael.

Re: [O] Org mode issue tracker

[Suvayu Ali]

On Wed, Sep 25, 2013 at 06:29:26PM +, Loyall, David wrote:
> > (I'm not so experienced with org-mode, so I would need at least some
> > assistance how such a TODO item should look like)
> 
> A 'headline' is a 'TODO item' if-and-only-if it contains one of the TODO 
> Keywords in the appropriate position.
> 
> See: http://orgmode.org/worg/dev/org-syntax.html
> 
> While you're in that document, have a look at the various structures that can 
> live inside a headline (for example, timestamps).
> 
> Everyone: Is that a proper answer to the question?  :)

Yes and no.  The pointer to the syntax is spot on.  But what would have
made it complete was a pointer to the API docs.  After all no need for
David to reimplement things.  Since he needs to work with TODOs, the
following section in the manual should help.



-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Org mode issue tracker

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> I have moved the tracker to Worg, discarding the old tracker file that was at
> that location.
>
> http://orgmode.org/worg/org-issues.html

Please note that the "Show Org source" button still shows the old Org file.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Org mode issue tracker

[Loyall, David]

> (I'm not so experienced with org-mode, so I would need at least some
> assistance how such a TODO item should look like)

A 'headline' is a 'TODO item' if-and-only-if it contains one of the TODO 
Keywords in the appropriate position.

See: http://orgmode.org/worg/dev/org-syntax.html

While you're in that document, have a look at the various structures that can 
live inside a headline (for example, timestamps).

Everyone: Is that a proper answer to the question?  :)

Thank you,
--Dave

Re: [O] using gnuplot's "splot" and "every" commands on org-mode table data

[Eric Schulte]

>
> Maybe I'm missing the point of the :missing header, but I find it
> easier and clearer to include the datafile missing command in the
> gnuplot code block.  I don't really see a need for the :missing
> header.  Maybe the need stems from wanting to be able to use different
> plotting packages to plot the same org table data, but it's not clear
> to me.
>

I agree that it is easier and more clear to include "set datafile
missing..." in the body of a gnuplot code block.  I *do* think that the
:missing header argument has value specifically as a way to replace
missing values in the original table data.

I've changed the behavior of the :missing header argument so that it
*only* replaces missing values in table data and does not add a "set
datafile missing..." line to the code block.

Cheers,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] org mode R remote code evaluation

[Eric Schulte]

Michael Albinus  writes:

> Alexander Vorobiev  writes:
>
>> Hi Michael,
>
> Hi Alex,
>
>> The patch seems to be working, the only thing I noticed is having
>> http://www.emacswiki.org/emacs/setup-cygwin.el loaded together with
>> the patched ob-core.el makes tramp prepend "/cygwin" to /tmp/. When I
>> disabled (require 'setup-cygwin) the patch works as expected. Outside
>> of org/babel setup-cygwin has no effect on Tramp.
>
> This problem does not seem to be related to org-mode code. Could
> somebody, please, commit my patch to org's repository? Thanks.
>

I'd rather not hard-code the value of "/tmp/".  Perhaps you could rework
the patch so that it introduces a new customizable variable (including a
documentation string) so that users can set the value for their system.

If you can keep the patch under 15LOC we can include it w/o requiring
FSF copyright assignment, otherwise see [1] for contribution details.
Also, please package the patch with git format-patch.

Thanks,

>
> I will try to find out what's up with Tramp and Cygwin. Sadly, it has
> been a misalliance very often :-(
>
>> Thanks,
>> Alex
>
> Best regards, Michael.
>


Footnotes: 
[1]   http://orgmode.org/worg/org-contribute.html

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

[O] [PATCH] Add check for assignment to hline relative references in table formulas.

[Rick Frankel]

* org-table.el (org-table-recalculate): Generate user error if
an hline relative reference is use on the LHS of a formula.
---
lisp/org-table.el | 2 ++
1 file changed, 2 insertions(+)

diff --git a/lisp/org-table.el b/lisp/org-table.el
index 246cf8d..a3197d3 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -3001,6 +3001,8 @@ known that the table will be realigned a little 
later anyway."

;; Insert constants in all formulas
(setq eqlist
(mapcar (lambda (x)
+ (if (string-match "^@-?I+" (car x))
+ (user-error "Can't assign to hline relative 
reference"))
  (when (string-match "\\`$[<>]" (car x))
(setq lhs1 (car x))
(setq x (cons (substring
--
1.8.0

Re: [O] Spurious exporting of text before first header

[Nicolas Goaziou]

Hello,

François Pinard  writes:

> The spirit behind :export: is that it marks exactly what is going to be
> exported.  This implies, in my understanding, that everything else does
> not get exported.  If the lines prior to the first header are exported
> whenever there is an :export: tag somewhere, it goes against the spirit
> and intent of :export: in my opinion.

I agree, this is a misfeature. This should be fixed in master.

Thank you for bringing it out.


Regards,

-- 
Nicolas Goaziou

[O] latex export subtree: org-latex-export-process

[Michael Bach]

Dear org-mode Users and Developers,

(org-mode v8.1) I use the following function for customizable latex
export processes
#+begin_src emacs-lisp
(defun my-auto-tex-cmd (backend)
  "When exporting from .org with latex,
  automatically run latex, pdflatex, or xelatex as appropriate,
  using latexmk."
  (let ((texcmd))
(cond ((string-match "LATEX_CMD: pdflatex" (buffer-string))
   (setq texcmd "latexmk -pdflatex=pdflatex -pdf %f"))
  ((string-match "LATEX_CMD: pdflatex-shell-escape" (buffer-string))
   (setq texcmd "latexmk -pdflatex=pdflatex --shell-escape -pdf
%f"))
  ((string-match "LATEX_CMD: xelatex" (buffer-string))
   (setq texcmd "latexmk -pdflatex=xelatex -pdf %f"))
  (t (setq texcmd "latexmk -pdf %f"))
  )
(setq org-latex-pdf-process (list texcmd
(add-hook 'org-export-before-processing-hook 'my-auto-tex-cmd)
#+end_src

which essentially uses an earlier idea[1].  Now this works well if I
export an .org buffer as a whole.  If I export a subtree, the
`buffer-string` only contains the subtree without the .org buffer
header, so the `string-match` always fails.

Any ideas on how to best integrate this function during a subtree
export?  Maybe inside a hook that is run before the subtree is narrowed
down?

Best Regards,
Michael

[1] http://lists.gnu.org/archive/html/emacs-orgmode/2010-10/msg00218.html

Re: [O] using orgtbl-sqlinsert

[Jason Riedy]

And Eric Abrahamsen writes:
> I've got a table I'm trying to insert into a sqlite
> database. I've been looking at orgtbl-sqlinsert and this
> page[fn:1], but I suspect all that is out of date.

FYI, I have changed employers and thus no longer have up-to-date
paperwork at the FSF for assignment.  That is only one reason I
haven't updated anything relevant to the orgtbl-sqlinsert
procrasti-working hack...

A more important reason is that I suspect a method using
org-babel would be much better.

I was looking for a semi-one-off method to convert a table
definition into something within my workflow at the time.  Org
mode was somewhat new and seemed useful (now proven that it is
very useful).  I was focused on *my* workflow, but the mindset
behind org-babel is more general.  I apologize, but I have not
had the time to look into adapting the mechanism or pursuing the
generalization.
-- 
Jason

Re: [O] A tutorial on using ox-rss.el to publish an Emacs-made blog

[Carsten Dominik]

On 25.9.2013, at 17:29, Scott Randby  wrote:

> On Wed, Sep 25, 2013 at 10:31 AM, Bastien  wrote:
>> Hi all,
>> 
>> reading Sacha's post on blogging with Emacs* pushed me to write this
>> small tutorial on how to use ox-rss.el to write/publish a blog with
>> Emacs and Org:
>> 
>> http://bzg.fr/blogging-from-emacs.html
>> 
>> Enjoy!
>> 
>> * 
>> http://sachachua.com/blog/2013/09/when-i-blog-with-emacs-and-when-i-blog-with-something-else/
>> 
>> --
>> Bastien
>> 
>> 
> 
> Thank you very much for this wonderful post.

+1.  Tis is the post that might put me over the edge and try it.

- Carsten

> 
> Scott Randby
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Has anything changed with R setup recently?

[John Hendy]

On Wed, Sep 25, 2013 at 10:02 AM, John Hendy  wrote:
> I started a post a bit ago and thought I had my R/Windows woes resolved:
> - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg57170.html
>
> I haven't change anything except for updating my path to the more
> recent R version I now have installed (used to have 2.15, now have
> 3.0.1). I have the following in .emacs:
>
> (setq org-babel-R-command "R/R-3.0.1/bin/x64/R --slave --no-save")
>
> This was previously working. I just got an error/backtrace when trying
> to export to LaTeX with babel blocks from Windows. To try and
> simplify, I just did =M-x R= and got the error:
>
> apply: Searching for program: no such file or directory, Rterm
>
> I've double checked my path, which is: C:\Program
> Files\R\R-3.0.1\bin\x64, and there are the following .exe files
> present: R, Rcmd, Rgui, Rscript, RSetReg, and Rterm.
>
> In re-checking the Worg page for R setup, I changed my path to the following:
>
> C:/Progra~1/R/R-3.0.1/bin/x64/R --slave --no-save
>
> On a fresh Emacs session when issuing =M-x R=, I get this:
>
> #+begin_src backtrace
>
> Debugger entered--Lisp error: (file-error "Searching for program" "no
> such file or directory" "Rterm")
>   start-process("R" # "Rterm" "--ess")
>   apply(start-process "R" # "Rterm" "--ess")
>   start-file-process("R" # "Rterm" "--ess")
>   apply(start-file-process "R" # "Rterm" "--ess")
>   comint-exec-1("R" # "Rterm" ("--ess"))
>   comint-exec(# "R" "Rterm" nil ("--ess"))
>   inferior-ess-make-comint("*R*" "R" "--ess  ")
>   ess-multi("R" # "--ess  ")
>   inferior-ess("--ess  ")
>   R(nil)
>   call-interactively(R t nil)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command nil nil)
>
> #+end_src
>
> Has anything changed recently that would require additional settings
> for R to function properly on Windows? Happy to provide more
> information. This is why I typically avoid using Org on Windows at all
> costs :) Linux just... works.
>

Solved... Even though I'd been uninstalling previous versions of R,
Windows leaves the old directories in C:\Program Files\R, and I think
ESS just searches the first one alpha-numerically, so I think it was
trying to use the old versions at R-2.14.0 instead of my new version.
I deleted all directories except R-3.0.1, and it now works (both =M-x
R= and export to LaTeX).


John

>
>
> Thanks,
> John

Re: [O] A tutorial on using ox-rss.el to publish an Emacs-made blog

[Scott Randby]

On Wed, Sep 25, 2013 at 10:31 AM, Bastien  wrote:
> Hi all,
>
> reading Sacha's post on blogging with Emacs* pushed me to write this
> small tutorial on how to use ox-rss.el to write/publish a blog with
> Emacs and Org:
>
> http://bzg.fr/blogging-from-emacs.html
>
> Enjoy!
>
> * 
> http://sachachua.com/blog/2013/09/when-i-blog-with-emacs-and-when-i-blog-with-something-else/
>
> --
>  Bastien
>
>

Thank you very much for this wonderful post.

Scott Randby

[O] org-indent-mode tabs bugs

[Rebel Neurofog]

Hi!

There are 2 things working not as promised after calling 'org-indent-mode':

1. Tabs aren't treated correctly.
For example a tab with indentation of 6 spaces counts from the beginning
so it gives 2 spaces from indentation border.
"\tABC" should turn into "XXABC"
while it actually turns into "XX  ABC"

2. *'s are NOT hidden as supposed to be.
Instead *'s are simply not highlighted.
So I've got something like this:
(*) Alpha
**(*) Betta
(*) Gamma
where (*) is for highlighted asterisk, * is plain-text asterisk.
According to "Clean view" description I of course expected to see the
following:
(*) Alpha
  (*) Betta
(*) Gamma
The described behavior is related to Emacs in Unicode RXVT terminal ('emacs
-nw').
In X11 Emacs (not xemacs) asterisks are hidden unless cursor right on the
hiding asterisk.
In Linux terminal (/dev/tty1-6) things look fine except than cursor becomes
invisible on hiding asterisks (what else should happen on tty when
foreground and background colors match?).
So I guess face-based hiding don't work well or at least should be improved
for X11, X11 terminal mode and Linux terminal mode.

My Org version is latest stable one: 8.2
It would be great to switch to cleaner view although

P. S. I'm also having strange issues in that Faces written (in my Emacs
module) for specific terminal don't work properly in X11. So I guess faces
should at least be tested in 3 systems.

Re: [O] [PATCH] babel support for ABC notation music files

[Eric Schulte]

Hi William,

I've added your ABC notation support to Org-mode.  Thanks for the
contribution!

If you have time to add ob-ABC documentation to [1] that would be much
appreciated but is not required.

Cheers,


Footnotes: 
[1]  http://orgmode.org/worg/org-contrib/babel/languages.html

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [O] Using org-lookup-all to count values in a table column

[William Denton]

For the record I was mailed off-list and it was pointed out I had the 
row/column order reversed in my formula.



#+TBLFM: $2@2='(length(org-lookup-all "F" '(remote(books,$3@2..$3@>)) nil))


Using @2$2 etc makes it all work.

Org spreadsheets are great!

Bill
--
William Denton
Toronto, Canada
http://www.miskatonic.org/

Re: [O] Spurious exporting of text before first header

[François Pinard]

"Sebastien Vauban" 
writes:

> Hi François,

Hello, Sebastien! :-)

>> [...] if I have text and other contents prior to the first header of
>> a file, those contents are indeed exported, while I would prefer not.
>> [...] I have hundreds of Org files and for them all, have some
>> personal conventions for their format and structure. [...}

> If you like text without initial heading in the exported file, but don't mind
> adding an heading in the Org buffer, you could add this:
> * Initial text :ignoreheading:
> and get what you want in the exported file.

I might have no other choice, but it would be sad.  As I said, I have
hundreds of Org files, all carefully crafted, rather nice to my eyes,
most of them using initial text for useful and special purpose.  Adding
an initial header everywhere would disrupt this nicety, for the sole
purpose of getting around what I consider to be an Org bug, or
limitation, or lack of happiness, depending on how you want to call it!

The spirit behind :export: is that it marks exactly what is going to be
exported.  This implies, in my understanding, that everything else does
not get exported.  If the lines prior to the first header are exported
whenever there is an :export: tag somewhere, it goes against the spirit
and intent of :export: in my opinion.

François

[O] Has anything changed with R setup recently?

[John Hendy]

I started a post a bit ago and thought I had my R/Windows woes resolved:
- http://www.mail-archive.com/emacs-orgmode@gnu.org/msg57170.html

I haven't change anything except for updating my path to the more
recent R version I now have installed (used to have 2.15, now have
3.0.1). I have the following in .emacs:

(setq org-babel-R-command "R/R-3.0.1/bin/x64/R --slave --no-save")

This was previously working. I just got an error/backtrace when trying
to export to LaTeX with babel blocks from Windows. To try and
simplify, I just did =M-x R= and got the error:

apply: Searching for program: no such file or directory, Rterm

I've double checked my path, which is: C:\Program
Files\R\R-3.0.1\bin\x64, and there are the following .exe files
present: R, Rcmd, Rgui, Rscript, RSetReg, and Rterm.

In re-checking the Worg page for R setup, I changed my path to the following:

C:/Progra~1/R/R-3.0.1/bin/x64/R --slave --no-save

On a fresh Emacs session when issuing =M-x R=, I get this:

#+begin_src backtrace

Debugger entered--Lisp error: (file-error "Searching for program" "no
such file or directory" "Rterm")
  start-process("R" # "Rterm" "--ess")
  apply(start-process "R" # "Rterm" "--ess")
  start-file-process("R" # "Rterm" "--ess")
  apply(start-file-process "R" # "Rterm" "--ess")
  comint-exec-1("R" # "Rterm" ("--ess"))
  comint-exec(# "R" "Rterm" nil ("--ess"))
  inferior-ess-make-comint("*R*" "R" "--ess  ")
  ess-multi("R" # "--ess  ")
  inferior-ess("--ess  ")
  R(nil)
  call-interactively(R t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)

#+end_src

Has anything changed recently that would require additional settings
for R to function properly on Windows? Happy to provide more
information. This is why I typically avoid using Org on Windows at all
costs :) Linux just... works.



Thanks,
John

[O] Rackspace is sponsoring orgmode.org hosting

[Carsten Dominik]

Hi everyone,

I guess it is appropriate to give a little shout-out to rackspace.com here, 
because a few month back they have decided to sponsor the webhosting for 
orgmode.org.  Jason Dunsmore set us up with a rackspace account a few years ago 
(2010 IIRC) and has done a great service to our community by running the server 
for us and giving us many additional capabilities beyond what we used to have.  
Orgmode.org is hosting its own git repositories which we all use to get our 
updates and to push patches.  It also runs the orgmode.org website and the worg 
pages, which are automatically created from the basic Org files whenever we 
push a change.  I don't know if any of you has ever experience downtime of 
orgmode.org in the last few year - I do not.

Over all these years Jason has put up with the hosting costs.  Now Rackspace is 
stepping in, letting us do all of this for free, and without any ads we would 
have to display (except this one, maybe :) )  The server works great, just a 
virtual Linux machine where we (Jason, Bastien and myself) can log in and do 
all the configuration we want.   A few minutes ago I tried creating a new VM, 
then resizing it, a lot of fun.  As far as I know, we have a carte blanche from 
Rackspace, so if we can think of an additional interesting service we want to 
provide, we could.  Let me know if you come up with an idea.

Kodos to Jason for all his (continuing!) great work, and Kodos for Rackspace 
for the sponsorship!

- Carsten


signature.asc
Description: Message signed with OpenPGP using GPGMail

[O] A tutorial on using ox-rss.el to publish an Emacs-made blog

[Bastien]

Hi all,

reading Sacha's post on blogging with Emacs* pushed me to write this
small tutorial on how to use ox-rss.el to write/publish a blog with
Emacs and Org:

http://bzg.fr/blogging-from-emacs.html

Enjoy!

* 
http://sachachua.com/blog/2013/09/when-i-blog-with-emacs-and-when-i-blog-with-something-else/

-- 
 Bastien

Re: [O] Pattern of global/file/headings variables/settings

[Thorsten Jolitz]

Karl Voit  writes:

Hi,

> I wonder how Org-mode turned out as it is with regard to settings

> If not: why can't there be a general pattern where a user can assume
> that #+foo (file) can be applied as :FOO: (heading) as well?

and I wonder why 

,--
| #+ATTR_HTML: :foo bar
`--

on top of a table becomes a ':attr_html' attribute of the table 's
property list, but the same thing on top of a headline becomes a
(keyword ...) that belongs to the section preceding the headline - when
parsing the buffer with `org-element-parse-buffer'. 

I would have expected that all affiliated keywords with the pattern

,--
| #+ATTR_<>: :foo bar
`--

directly on top of an element are converted to attributes of the element
they are attached to, no matter what <> actually looks like
(or, at least, when <> is listed in `org-export-backends' or
`org-export--registered-backends' or so).

-- 
cheers,
Thorsten

[O] bug#9179: 24.0.50; Org-agenda window splitting does not use full frame when fraction set to 1.0

[Carsten Dominik]

>> 1. M-: (setq org-agenda-window-frame-fractions '(1.0 . 1.0)) RET
>> 2. M-x org-agenda a
>>
>> Expected results: The *Org Agenda* buffer occupies the entire frame
>> Actual results: The *Org Agenda* buffer occupies the entire frame EXCEPT
>> for a five line window at the top of the frame
>
> Due to fact that `fit-window-to-buffer' no more deletes other windows by
> side-effect.  Hence for the '(1.0 . 1.0) case `org-fit-agenda-window'
> (or `org-fit-window-to-buffer') should call `delete-other-windows' or
> something the like.

Hi,

this bug s fixed in the Org git repository.  The fix will move into Emacs 
eventually.

- Carsten


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

Eric Schulte  writes:

 
 While we are at editing code blocks inline (I also do this quite often).
 
 This might have been asked before, but in code blocks we have
 
 - syntax highlighting
 - indenting using the code block language settings
 
 but would it be possible to have, when the cursor is in a code block,
 the menus and shortcuts for the language mode enabled, i.e. complete
 support for editing the code block language, as in the special buffer,
 but inline in org? Evaluationg single lines of code directly from the
 code block in org would be *brilliant*.
>>>
>>> This is very complicated, because such functionality needs
>>> the entire environment of a mode.  I think there are some solutions
>>> which allow multiple major modes - but I don't think we will go
>>> there with Org.
>>
>> This is definitely not an easy task, but which I think would be an very
>> useful feature, making the work-flow of using embedded code much faster.
>>
>
> I don't think this is an attainable goal.  Major modes assume that they
> are the sole owners of the current buffer and of the related state.
> Breaking this assumption would open a deep can of major-mode-specific
> problems which would each require major-mode-specific solutions.

I agree that sounds quite difficult, especially as it would involve
quite a number of different modes when different languages are used. 

>
> The only solution I see would be to somehow give each code block it's
> own buffer, and then trick Emacs into treating multiple buffers as a
> single buffer for purposes of display and cursor movement.  If someone
> wanted to develop such functionality I think it would best be done
> independent of Org-mode.

Keep in mind my very limited emacs knowledge - but wouldn't it be
possible to switch between modes depending where the cursor is?
This would mean the buffer is in R-mode, when the cursor is in a R code
block, and in org-mode, when the cursor is outside. One could even
enable minor-org-mode to keep some functionality n the code blocks?

I know this would not be ideal, but wouldn't that be possible?

Thanks a lot,

Rainer

>
> Best,
<#secure method=pgpmime mode=sign>

-- 
Rainer M. Krug

email: RMKruggmailcom

Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer

[Eric Schulte]

>>> 
>>> While we are at editing code blocks inline (I also do this quite often).
>>> 
>>> This might have been asked before, but in code blocks we have
>>> 
>>> - syntax highlighting
>>> - indenting using the code block language settings
>>> 
>>> but would it be possible to have, when the cursor is in a code block,
>>> the menus and shortcuts for the language mode enabled, i.e. complete
>>> support for editing the code block language, as in the special buffer,
>>> but inline in org? Evaluationg single lines of code directly from the
>>> code block in org would be *brilliant*.
>>
>> This is very complicated, because such functionality needs
>> the entire environment of a mode.  I think there are some solutions
>> which allow multiple major modes - but I don't think we will go
>> there with Org.
>
> This is definitely not an easy task, but which I think would be an very
> useful feature, making the work-flow of using embedded code much faster.
>

I don't think this is an attainable goal.  Major modes assume that they
are the sole owners of the current buffer and of the related state.
Breaking this assumption would open a deep can of major-mode-specific
problems which would each require major-mode-specific solutions.

The only solution I see would be to somehow give each code block it's
own buffer, and then trick Emacs into treating multiple buffers as a
single buffer for purposes of display and cursor movement.  If someone
wanted to develop such functionality I think it would best be done
independent of Org-mode.

Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

[O] Pattern of global/file/headings variables/settings

[Karl Voit]

Hi!

I wonder how Org-mode turned out as it is with regard to settings
that could be done in .emacs (user), as file-local ones (file), or
with properties (heading).

As an example:

[1] mentions:
 #+startup: beamer
 #+LaTeX_CLASS: beamer
 #+LaTeX_CLASS_OPTIONS: [bigger]
 #+BEAMER_FRAME_LEVEL: 2

I could find "EXPORT_LATEX_CLASS" and "EXPORT_LATEX_CLASS_OPTIONS"
using full-text search in [2]. However, I was not able to locate any
property which relates to #+BEAMER_FRAME_LEVEL, e.g.

So: what is the pattern here? Which setting goes to setq (user),
#+FOO (file), :PROPERTY: (heading)?

I assume that every additional possibility (of the three) relates to
manual effort to be implemented. Right?

If not: why can't there be a general pattern where a user can assume
that #+foo (file) can be applied as :FOO: (heading) as well?


Background: I do not want to create a whole new Org-mode file for
just one single beamer presentation. I love it when I can keep *all*
relevant data within its project heading, wherever that might be
located in my (few) Org-mode files. Thus, as a sub-heading of
business.org > projects > customerA > reports > final-report I want
to add my beamer presentation data as well.

Thanks for clarifying!

  1. http://orgmode.org/worg/exporters/beamer/tutorial.html
  2. http://orgmode.org/org.html
-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: [O] Org mode issue tracker

[Sebastien Vauban]

Hi Michael,

Michael Albinus wrote:
> "Sebastien Vauban" 
>
 The other solution that I'd see would be using Emacs' own bug tracker (the
 `org' package is already known to them), if that's
 possible. Anyway, having the
 bugs in an Org file seems natural too!
>>>
>>> I think this is a great idea.  A combination of an Org file (either
>>> public or private) and the Emacs bug tracker with Org package tags
>>> should be able to handle our needs.
>>>
>>> I see only one potential problem, is there an easy way to subscribe to
>>> only a specific package tag on the Emacs bug tracker?  I imagine most
>>> contributors following Org bugs will not be interested in other Emacs
>>> bugs.
>>
>> I don't know. I guess this should be asked directly to them. Indeed, it'd be
>> good to have a (virtual) newsgroup with only bugs related to `org', like what
>> exists for Stack Overflow.
>
> There is the debbugs package on ELPA. The frontend, debbugs-gnu, allows
> to filter for packages and tags. Try
>
> (debbugs-gnu '("serious" "important" "normal") '("org-mode"))

I did not know. I must try it, for sure!  It may be easier than the Web
interface, which I find sometimes difficult to use (to find one's bug without
remembering its ID).

> On my wannabe todo list is a package debbugs-org.el, which shows the
> entries as TODO items. If the org community decides to use debbugs as
> issue tracker, it would give me a push.

I'd find that a promising feature...

> (I'm not so experienced with org-mode, so I would need at least some
> assistance how such a TODO item should look like)

I don't think that's the problem ;-)

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] HTML export -- footnote section -- blank lines between footnote number and footnote text

[D. C. Toedt]

I thought the footnotes would come out as follows, which I believe is
the way it did before I upgraded from org version 7.9.3 (I think it
was):

==BEGIN EXAMPLE==

[FOOTNOTES:]

[9]  Agreement-Related definition: This defined term is available for use
in, for example, attorneys' fees clauses, limitations of liability,
and the like.

==END EXAMPLE==

Here's the HTML generated by the exporter -- note that the footnote
number comes just before the  containing the text:

==BEGIN HTML==

[9] 
Agreement-Related definition:  This defined term is available
for use in, for example, attorneys' fees clauses, limitations of
liability, and the like.


==END HTML==


--

D
. C. Toedt III  (my last name is pronounced "Tate")
Attorney and arbitrator -- contracts and intellectual property

d...@toedt.com LinkedIn: dctoedtCalendar (redacted)
O: +1 (713) 364-6545C: +1 (713) 516-8968

Houston, Texas (Central time zone)
B
log: On Contracts.com
Book project: Common Draft encyclopedic dictionary of contract clauses

Unless expressly stated otherwise, this message is not intended
to serve as an electronic signature nor as assent to an agreement.




On Wed, Sep 25, 2013 at 7:35 AM, Bastien  wrote:
> Hi,
>
> "D. C. Toedt"  writes:
>
>> The footnote section in my HTML-export doc has the footnote number
>> separated from the footnote text by a blank line.  See
>> http://www.commondraft.org for the document.
>
> What did you expect instead of this rendering?
>
> Did you try to adapt the CSS to get what you need?
>
> Thanks,
>
> --
>  Bastien

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Christian Moe]

>>  - when t, export completely all property drawers as examples;
>> 
>>  - when nil, do not export property drawers (default value);
>> 
>>  - when set to a list of strings, export property drawers as examples
>>but only include properties matching these strings;

+1

Christian

Re: [O] HTML export -- footnote section -- blank lines between footnote number and footnote text

[Bastien]

Hi,

"D. C. Toedt"  writes:

> The footnote section in my HTML-export doc has the footnote number
> separated from the footnote text by a blank line.  See
> http://www.commondraft.org for the document.

What did you expect instead of this rendering?

Did you try to adapt the CSS to get what you need?

Thanks,

-- 
 Bastien

Re: [O] Small org-contacts patch

[Bastien]

Hi Simon,

Simon Thum  writes:

> the attached patch solves the problem of having hexified strings in
> hte vCard export. It happens when you are entering tel: links and
> phone numbers that start with `+`. The plus sign causes the link
> insert helper to hexify the url.
>
> In tel: links the plus makes sense for international numbers. The C-c 
> C-l helper makes that
>
> [[tel:%-encoded glibberish][tel:+49 xxx]]
>
> with the %-encoded part ending up in vCards. Which my phone accepts
> but does not dial properly. So far I cleaned them manually but this
> seems a better solution.

applied in master, thanks.

-- 
 Bastien

Re: [O] a lisp question

[Bastien]

Nick Dokos  writes:

> "tuma...@gmail.com"  writes:
>
>> How can i convert (1 2 3 5 7 8 9 10 11 12 13) to
>> ((1 2 3 ) (5) (7) (8 9) (10 11 12 13))?
>>
>
> Two problems:
>
> Wrong list: try comp.lang.lisp instead.
> Incomplete problem description: see "How to ask questions
> the smart way" at http://www.catb.org/esr/faqs/smart-questions.html.

Well, not really *the* good answer, but Org has a function to easily
get a sublist from a list:

(org-sublist '(1 2 3 4 5 6) 2 4)
=> (2 3 4)

So this might be handy in this case.

-- 
 Bastien

[O] [PATCH] babel support for ABC notation music files

[William Waites]

For example:

* John MacColl's March to Kilbowie Cottage
  #+begin_src abc :file john_maccol_kilbowie.svg :cmdline -g
   T: John MacColl's March To Kilbowie Cottage
   R: March
   M: 4/4
   L: 1/8
   K: Amix
   A>B|: c4 c>B A>c | e4 f>e cB cc A>B | cc B2 A>B |
   c4 c>B A>c | e4 f>e ce f>c e>A BB :|2 A2 A2 A2 f>=g 
||
   a2-a>f e>c Bc e>=g f>c e>c | a>f eB | cc B2 f>=g |
   a2-a>f e>c Bc e>=g f>c e>c | fA B=g |
   a2-a>f e>c Bc e>=g f>c e>c | a>f eB | cc B2 A>B |
   c4 c>B A>c | e4 f>e ce f>c e>A BB |
   | : A>c Bf ee ff cc Bf ef e>c B2 c>B |
   A>c Bf ee ff ce f>c e>A BB :|2 A2 
A2 A2 e>d ||
   cc A>c e>A | ce f>e c>d | e>c BB | cc B2 e>d|
   cc A>c e>A | ce f>e c>d | e>f cA Bd |
   cc A>c e>A | ce f>e c>d | e>c BB | cc B2 A>B |
   c4 c>B A>c | e4 f>e ce f>c e>A B>From 1709deacfdbb6eb76edf5878df106d9e1cc676fa Mon Sep 17 00:00:00 2001
From: William Waites 
Date: Wed, 25 Sep 2013 12:18:55 +0100
Subject: [PATCH 1/2] Initial version of ABC notation handling for Babel

---
 lisp/ob-abc.el |   87 
 1 file changed, 87 insertions(+)
 create mode 100644 lisp/ob-abc.el

diff --git a/lisp/ob-abc.el b/lisp/ob-abc.el
new file mode 100644
index 000..5ad7409
--- /dev/null
+++ b/lisp/ob-abc.el
@@ -0,0 +1,87 @@
+;;; ob-abc.el --- org-babel functions for template evaluation
+
+;; Copyright (C) Free Software Foundation
+
+;; Author: William Waites
+;; Keywords: literate programming, music
+;; Homepage: http://www.tardis.ed.ac.uk/wwaites
+;; Version: 0.01
+
+;;; License:
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3, or (at your option)
+;; any later version.
+;;
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs; see the file COPYING.  If not, write to the
+;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+;; Boston, MA 02110-1301, USA.
+
+;;; Commentary:
+
+;;; This file adds support to Org Babel for music in ABC notation.
+;;; It requires that the abcm2ps program is installed.
+;;; See http://moinejf.free.fr/
+
+(require 'ob)
+
+;; optionally define a file extension for this language
+(add-to-list 'org-babel-tangle-lang-exts '("abc" . "abc"))
+
+;; optionally declare default header arguments for this language
+(defvar org-babel-default-header-args:abc
+  '((:results . "file") (:exports . "results"))
+  "Default arguments to use when evaluating an ABC source block.")
+
+(defun org-babel-expand-body:abc (body params)
+  "Expand BODY according to PARAMS, return the expanded body."
+  (let ((vars (mapcar #'cdr (org-babel-get-header params :var
+(mapc
+ (lambda (pair)
+   (let ((name (symbol-name (car pair)))
+	 (value (cdr pair)))
+	 (setq body
+	   (replace-regexp-in-string
+		(concat "\$" (regexp-quote name))
+		(if (stringp value) value (format "%S" value))
+		body
+ vars)
+body))
+
+(defun org-babel-execute:abc (body params)
+  "Execute a block of ABC code with org-babel.  This function is
+   called by `org-babel-execute-src-block'"
+  (message "executing Abc source code block")
+  (let* ((result-params (split-string (or (cdr (assoc :results params)
+	 (cmdline (cdr (assoc :cmdline params)))
+	 (out-file ((lambda (el)
+		  (or el
+			  (error "abc code block requires :file header argument")))
+		;;; For SVG or EPS output, abcm2ps will add a number for a particular page
+		;;; automatically. This needs to be specified in the :file argument and stripped
+		;;; stripped out here. There is likely a better way to do this.
+		(replace-regexp-in-string "001" "" (cdr (assoc :file params)
+	 (in-file (org-babel-temp-file "abc-"))
+	 (cmd (concat "abcm2ps" " " cmdline
+		  " -O " (org-babel-process-file-name out-file)
+		  " " (org-babel-process-file-name in-file
+(with-temp-file in-file (insert (org-babel-expand-body:abc body params)))
+(org-babel-eval cmd "")
+;;; indicate that the file has been written
+nil))
+
+;; This function should be used to assign any variables in params in
+;; the context of the session environment.
+(defun org-babel-prep-session:abc (session params)
+  "Return an error because abc does not support sessions."
+  (error "ABC does not support sessions"))
+
+(provide 'ob-abc)
+;;; ob-abc.el ends here
--
1.7.10.4

>From 0fb2613d7d321cd259c48e844f32df070c2f9a6f Mon Sep 17 00:00:00 2001
From: William Waites 
Date: Wed, 25 Sep 2013 13:24:42 +0100
Subject: [PATCH 2/2] improve handling of output file types

---
 lisp/ob-abc.el |   19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Carsten Dominik]

On 25.9.2013, at 14:13, Nicolas Goaziou  wrote:

> Carsten Dominik  writes:
> 
>> This sounds good to me.  How about allowing also a function
>> as a value and that function will receive the list of properties
>> and do with it as it pleases.
> 
> At first I thought about it but I realized that was exactly what
> a filter could do. Do we need to introduce redundancy here?

Not really.  It would simplify processing to have the list instead
of a string, but indeed, a filter can accomplish all of it.

Regards

- Carsten

> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou



signature.asc
Description: Message signed with OpenPGP using GPGMail

[O] HTML export -- footnote section -- blank lines between footnote number and footnote text

[D. C. Toedt]

The footnote section in my HTML-export doc has the footnote number
separated from the footnote text by a blank line.  See
http://www.commondraft.org for the document.

Here's an example of what it looks like:


==BEGIN EXAMPLE==

[TEXT:]

The term "Agreement-Related"[9] refers to something – for example, a
dispute – that arises out of or relates to any of the following:
[remainder of section omitted]


[FOOTNOTES:]

[9]

Agreement-Related definition: This defined term is available for use
in, for example, attorneys' fees clauses, limitations of liability,
and the like.


==END EXAMPLE==


DETAILS:

Org version 8.2-4 (version 20130923) on Mac OS X Mountain Lion.

I upgraded to 8.2-4 by uninstalling and reinstalling Emacs after
encountering the ELPA bug (see
http://lists.gnu.org/archive/html/emacs-orgmode/2013-05/msg00176.html).

Relevant portion of my .emacs file:

 '(org-footnote-section nil)
 '(org-html-footnote-format "[%s]")

In the .org file itself:

#+STARTUP: nofnadjust indent showstars

QUESTION:

Is this a bug in the code, or a PICNIC problem
(http://en.wikipedia.org/wiki/User_error)?


--

D
. C. Toedt III  (my last name is pronounced "Tate")
Attorney and arbitrator -- contracts and intellectual property

d...@toedt.com LinkedIn: dctoedtCalendar (redacted)
O: +1 (713) 364-6545C: +1 (713) 516-8968

Houston, Texas (Central time zone)
B
log: On Contracts.com
Book project: Common Draft encyclopedic dictionary of contract clauses

Unless expressly stated otherwise, this message is not intended
to serve as an electronic signature nor as assent to an agreement.

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Thorsten Jolitz]

Nicolas Goaziou  writes:

Hello,

> There may be a slightly different option available: we can introduce
> a new defcustom, e.g., `org-export-with-node-properties' (what symbol to
> use for short item in OPTIONS?), which will trigger the following
> behaviour:
>
>   - when t, export completely all property drawers as examples;
>
>   - when nil, do not export property drawers (default value);
>
>   - when set to a list of strings, export property drawers as examples
> but only include properties matching these strings;

with the last option as "list of strings or regexp's" this would be
exactly what I would have needed in some practical use cases, and it
seems to be just natural given the dual nature of property drawers
(storage for Org-mode-internal data and storage for use-case related
data).

With 'strings or regexp's' I mean that it should be possible to match on
key-prefixes, like FOO in the following example

* My Header
  :PROPERTIES:
  :CUSTOM_ID: ABC123
  :FOO_BAR:  13
  :FOO_FOO:  bar bar
  :END:

no matter if the user actually has to give a regexp or if ox.el takes care of
bulding a regexp from a given string like 

,--
| (let ((rgxp (concat strg  "[_-[:word:]]*"
`--

or so...

-- 
cheers,
Thorsten

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Nicolas Goaziou]

Carsten Dominik  writes:

> This sounds good to me.  How about allowing also a function
> as a value and that function will receive the list of properties
> and do with it as it pleases.

At first I thought about it but I realized that was exactly what
a filter could do. Do we need to introduce redundancy here?


Regards,

-- 
Nicolas Goaziou

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Carsten Dominik]

On 25.9.2013, at 13:51, Nicolas Goaziou  wrote:

> Hello,
> 
> Carsten Dominik  writes:
> 
>> One possible remaining option would be to introduce user variables
>> org-BACKEND-format-property-drawer-function in analogy
>> org-BACKEND-format-drawer-function.  This would provide an easy way
>> to configure export of the property drawer as a whole, in a way
>> that could be file-local.
>> 
>> I would like to have this option.  Nicolas, would you agree to a patch
>> in this direction?
> 
> Unfortunately, this is a bit more difficult.
> 
> Indeed, `node-property' elements are distinct from `property-drawer'
> elements. I.e., if we want to export property drawers as examples, as
> you suggested earlier in this thread, we need to implement two functions
> in each back-end: a transcoder for `node-property' and another one for
> the `property-drawer' itself. Similarly, in order to implement your
> current suggestion, we need both
> `org-BACKEND-format-property-drawer-function' and
> `org-BACKEND-format-node-property-function'.
> 
> IMO, this is a bit much for defcustoms, which are sold as an easy way to
> configure Org behaviour.
> 
> There may be a slightly different option available: we can introduce
> a new defcustom, e.g., `org-export-with-node-properties' (what symbol to
> use for short item in OPTIONS?), which will trigger the following
> behaviour:
> 
>  - when t, export completely all property drawers as examples;
> 
>  - when nil, do not export property drawers (default value);
> 
>  - when set to a list of strings, export property drawers as examples
>but only include properties matching these strings;

This sounds good to me.  How about allowing also a function
as a value and that function will receive the list of properties
and do with it as it pleases.

I like it!

- Carsten

> 
> In that case, we need to:
> 
>  1. patch ox.el to previous behaviour;
>  2. write two transcoder functions for each back-end where property
> drawers make sense and install them in back-end definitions.
> 
> For example, in the `latex' back-end, such functions could be:
> 
>  (defun org-latex-property-drawer (property-drawer contents info)
>"Transcode a PROPERTY-DRAWER element from Org to LaTeX.
>  CONTENTS is the contents of the drawer, as a string.  INFO is
>  a plist holding contextual information."
>(and (org-string-nw-p contents)
> (format "\\begin{verbatim}\n%s\\end{verbatim}" contents)))
> 
>  (defun org-latex-node-property (node-property contents info)
>"Transcode a NODE-PROPERTY element from Org to LaTeX.
>  CONTENTS is nil.  INFO is a plist holding contextual information."
>(format "%s:%s"
>(org-element-property :key node-property)
>(let ((value (org-element-property :value node-property)))
>  (if value (concat " " value) ""
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Nicolas Goaziou]

Hello,

Carsten Dominik  writes:

> One possible remaining option would be to introduce user variables
> org-BACKEND-format-property-drawer-function in analogy
> org-BACKEND-format-drawer-function.  This would provide an easy way
> to configure export of the property drawer as a whole, in a way
> that could be file-local.
>
> I would like to have this option.  Nicolas, would you agree to a patch
> in this direction?

Unfortunately, this is a bit more difficult.

Indeed, `node-property' elements are distinct from `property-drawer'
elements. I.e., if we want to export property drawers as examples, as
you suggested earlier in this thread, we need to implement two functions
in each back-end: a transcoder for `node-property' and another one for
the `property-drawer' itself. Similarly, in order to implement your
current suggestion, we need both
`org-BACKEND-format-property-drawer-function' and
`org-BACKEND-format-node-property-function'.

IMO, this is a bit much for defcustoms, which are sold as an easy way to
configure Org behaviour.

There may be a slightly different option available: we can introduce
a new defcustom, e.g., `org-export-with-node-properties' (what symbol to
use for short item in OPTIONS?), which will trigger the following
behaviour:

  - when t, export completely all property drawers as examples;

  - when nil, do not export property drawers (default value);

  - when set to a list of strings, export property drawers as examples
but only include properties matching these strings;

In that case, we need to:

  1. patch ox.el to previous behaviour;
  2. write two transcoder functions for each back-end where property
 drawers make sense and install them in back-end definitions.

For example, in the `latex' back-end, such functions could be:

  (defun org-latex-property-drawer (property-drawer contents info)
"Transcode a PROPERTY-DRAWER element from Org to LaTeX.
  CONTENTS is the contents of the drawer, as a string.  INFO is
  a plist holding contextual information."
(and (org-string-nw-p contents)
 (format "\\begin{verbatim}\n%s\\end{verbatim}" contents)))

  (defun org-latex-node-property (node-property contents info)
"Transcode a NODE-PROPERTY element from Org to LaTeX.
  CONTENTS is nil.  INFO is a plist holding contextual information."
(format "%s:%s"
(org-element-property :key node-property)
(let ((value (org-element-property :value node-property)))
  (if value (concat " " value) ""


Regards,

-- 
Nicolas Goaziou

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Carsten Dominik]

On 25.9.2013, at 12:53, Thorsten Jolitz  wrote:

> Carsten Dominik  writes:
> 
>> 3. The only exception to this rule are property drawers, which will
>>   currently not be exported by any of the backends.  Nicolas
>>   proposed to define a derived backend that does export the property
>>   drawer, or he proposed to use macros to extract specific properties
>>   to include into the exported file.  Both are viable options.
> 
>> One possible remaining option would be to introduce user variables
>> org-BACKEND-format-property-drawer-function in analogy
>> org-BACKEND-format-drawer-function.  This would provide an easy way
>> to configure export of the property drawer as a whole, in a way
>> that could be file-local.
>> 
>> I would like to have this option
> 
> +1
> 
> property drawers are just too useful to restrict them to Org-mode's 
> internal meta-data, and anything that makes it easier to export them
> when used for 'use case' related meta-data or as simple DB is welcome. 

To be sure:  Nicolas' argument that other functions dump data into
the property drawer is completely right, and so I also think that
one would hardly ever want to export the complete drawer.  But
through a function that selects (or deselects), it is useful.

- Carsten

> 
> -- 
> cheers,
> Thorsten
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Thorsten Jolitz]

Carsten Dominik  writes:

> 3. The only exception to this rule are property drawers, which will
>currently not be exported by any of the backends.  Nicolas
>proposed to define a derived backend that does export the property
>drawer, or he proposed to use macros to extract specific properties
>to include into the exported file.  Both are viable options.

> One possible remaining option would be to introduce user variables
> org-BACKEND-format-property-drawer-function in analogy
> org-BACKEND-format-drawer-function.  This would provide an easy way
> to configure export of the property drawer as a whole, in a way
> that could be file-local.
>
> I would like to have this option

+1

property drawers are just too useful to restrict them to Org-mode's 
internal meta-data, and anything that makes it easier to export them
when used for 'use case' related meta-data or as simple DB is welcome. 

-- 
cheers,
Thorsten

Re: [O] org mode R remote code evaluation

[Michael Albinus]

Alexander Vorobiev  writes:

> Hi Michael,

Hi Alex,

> The patch seems to be working, the only thing I noticed is having
> http://www.emacswiki.org/emacs/setup-cygwin.el loaded together with
> the patched ob-core.el makes tramp prepend "/cygwin" to /tmp/. When I
> disabled (require 'setup-cygwin) the patch works as expected. Outside
> of org/babel setup-cygwin has no effect on Tramp.

This problem does not seem to be related to org-mode code. Could
somebody, please, commit my patch to org's repository? Thanks.

I will try to find out what's up with Tramp and Cygwin. Sadly, it has
been a misalliance very often :-(

> Thanks,
> Alex

Best regards, Michael.

Re: [O] SUMMARY: [Feature Request] Make property-drawers exportable

[Carsten Dominik]

OK,

now that I have made a fool out of myself, I think I understand now how
things work, and what I did not understand correctly in the
discussion so far.

1. I misunderstood that drawers could not be exported in
   general with the new exporter.   This is wrong, drawers are
   exported just fine as long as org-export-with-drawers
   is t or contains a list of drawer names that should be
   exported.  The reason why I misunderstood was a bug in my test
   file where I have #+OPTIONS: d:(LOGBOOK) instead of d:("LOGBOOK")

2. If a drawer is selected for export, it will be exported as if it
   was part of the Org file.

3. The only exception to this rule are property drawers, which will
   currently not be exported by any of the backends.  Nicolas
   proposed to define a derived backend that does export the property
   drawer, or he proposed to use macros to extract specific properties
   to include into the exported file.  Both are viable options.

I think this is all well and fine and very well argued.

One possible remaining option would be to introduce user variables
org-BACKEND-format-property-drawer-function in analogy
org-BACKEND-format-drawer-function.  This would provide an easy way
to configure export of the property drawer as a whole, in a way
that could be file-local.

I would like to have this option.  Nicolas, would you agree to a patch
in this direction?

- Carsten



On 25.9.2013, at 11:34, Carsten Dominik  wrote:

> 
> On 25.9.2013, at 11:31, Carsten Dominik  wrote:
> 
>> Hi everyone,
>> 
>> I would like to come back to this issue.
>> 
>> While I can follow the argumentation that drawers are meta data and that it 
>> is really hard for a backend to do something general and correct with them, 
>> I am still wondering if it wouldn't be good to have some default way to 
>> export them anyway.  I'd be perfectly content to have is such that drawers 
>> can be exported as an @example block.  I also think that the export of 
>> drawers should definitely be OFF by default.
>> 
>> Having the default backends allow export of drawers as examples opens the 
>> door to use filters to modify it.  This has the advantage that a new backend 
>> does not have to be defined.  I am experimenting right now with defining 
>> filters with Babel in buffers, and I am finding this a powerful way to tweak 
>> the export of an individual file.
> 
> P.S. of course there is also the possibility that I could use Babel to define 
> or temporarily modify an export backend on the fly - but I have not figured 
> out how this might work..
> 
> 
> 
>> 
>> The reason why I am bringing this up is the following:
>> 
>> I am reviving the Org Issues file, see the other thread on the mailing list. 
>>  I would like to be able to export the LOOGBOOK state changes, and these are 
>> naturally located in a drawer.
>> 
>> The problem here is that the export is happening on worg, in an automatic 
>> way.  So it is not really an easy option to define a new backend that will 
>> be used for just this file, because publishing on Worg uses org-to-html.
>> 
>> Now, being the person with the keys, I *could*, of course go and define a 
>> special backend on Worg that does what I want - but I do also understand the 
>> wish expressed by a couple of people in this thread.
>> 
>> We still have the variable org-export-with-drawers in ox.el.  My proposal 
>> would be to set the default to nil, plain and simple, and use a t value to 
>> make drawers export as @example.  Safe enough, and easy enough.
>> 
>> Regards
>> 
>> - Carsten
>> 
>> On 17.6.2013, at 21:04, Nicolas Goaziou  wrote:
>> 
>>> Thorsten Jolitz  writes:
>>> 
 Nicolas Goaziou  writes:
>>> 
> Property drawers are Org meta data, they are not for user's
> cosumption. Though you can export some properties with macros (see
> {{{property{NAME macros).
 
 I don't really agree. Property drawers are for meta data used by
 Org-mode too, obviously, but they are perfectly suited for meta-data
 about the document, as well as those simple data-base features described
 in the manual.
>>> 
>>> It seems I wasn't clear enough. More on this below.
>>> 
 Why deny Org users the full benefit of these other uses for
 property-drawers by denying them the possibility to export their
 document meta-data or data-bases?
>>> 
>>> I don't deny anyone the right code this:
>>> 
>>> (defun my-latex-property-drawer (drawer contents info)
>>>  (concat "\\begin{example}\n"
>>>  (org-element-interpret-data drawer)
>>>  "\\end{example}"))
>>> 
>>> (org-export-define-derived-backend 'my-latex 'latex
>>>  :translate-alist '((property-drawer . my-latex-property-drawer)))
>>> 
>>> [...]
>>> 
 And whats wrong with a simple CD collection database implemented with
 property-drawers, as described in the manual? Why shouldn't people be
 allowed to export their CD database to some text-formatting backend?
>>> 
>>> Database example is interesting. My poi

Re: [O] Org mode issue tracker

[Michael Albinus]

"Sebastien Vauban" 
writes:

> Hi Suvayu,

Hi,

>>> The other solution that I'd see would be using Emacs' own bug tracker (the
>>> `org' package is already known to them), if that's
>>> possible. Anyway, having the
>>> bugs in an Org file seems natural too!
>>
>> I think this is a great idea.  A combination of an Org file (either
>> public or private) and the Emacs bug tracker with Org package tags
>> should be able to handle our needs.
>>
>> I see only one potential problem, is there an easy way to subscribe to
>> only a specific package tag on the Emacs bug tracker?  I imagine most
>> contributors following Org bugs will not be interested in other Emacs
>> bugs.
>
> I don't know. I guess this should be asked directly to them. Indeed, it'd be
> good to have a (virtual) newsgroup with only bugs related to `org', like what
> exists for Stack Overflow.

There is the debbugs package on ELPA. The frontend, debbugs-gnu, allows
to filter for packages and tags. Try

(debbugs-gnu '("serious" "important" "normal") '("org-mode"))

On my wannabe todo list is a package debbugs-org.el, which shows the
entries as TODO items. If the org community decides to use debbugs as
issue tracker, it would give me a push.

(I'm not so experienced with org-mode, so I would need at least some
assistance how such a TODO item should look like)

> Best regards,
>   Seb

Best regards, Michael.

Re: [O] Org mode issue tracker

[Carsten Dominik]

Hi Sebastiaan,

I have added your issues.

(P.S. this sounds really funny and reminds me of Marvin from the
"Hitchhikers Guide to the Galaxy" does solve "all of the
major mathematical, physical, chemical, biological, sociological,
philosophical, etymological,meteorological and psychological
problems of the Universe *except his own*, three times over,")

- Carsten

On 25.9.2013, at 11:04, Sebastien Vauban  wrote:

> Carsten Dominik wrote:
>> On 25.9.2013, at 09:51, Sebastien Vauban  wrote:
>>> Carsten Dominik wrote:
 we do not have an issue tracker for Org.  However, if you
 have some time to help, the file with open issues that need
 attention can be found here:
 
 https://dl.dropboxusercontent.com/u/530458/org-tracker.html
 
 Note that I do not enter every issue into this file.  Normally I wait
 and see if a report gets addressed on the mailing list, and only
 if that does not happen, than I make a note in this file.  I think
 this keeps it more manageable for me - an official online bug tracker
 would probably quickly fill with many small things we can better
 handle on the list.
 
 If you feel that this is not going well enough and if I am missing
 important reports in this way, let me know and we will find a better
 solution.
 
 Some of these bugs still need confirmation by a second party,
 and patches are always welcome.  If possible, reply in
 the original thread, while still mentioning the bug number
 in the above link.
>>> 
>>> The other solution that I'd see would be using Emacs' own bug tracker (the
>>> `org' package is already known to them), if that's possible. Anyway, having 
>>> the
>>> bugs in an Org file seems natural too!
>>> 
>>> But shouldn't it, maybe, be in a Git project, so that other people can edit 
>>> it?
>>> 
>>> And choosing to have the `Assignee' (or `ASSIGNEE') property be the official
>>> Org way to delegate a task to someone would help?
>>> 
>>> Regarding the list itself, if I may, I would add 3 problems (identified by 
>>> the
>>> date and time it has been sent on the Org mailing list):
>> 
>> To make my life easier, cold you please provide gmane links?
> 
> DONE ;-)  See below.
> 
>>> 1. 20130315.1805: Background color reset for links and DONE headlines
>>> 
>>>  Allow to have more faces than just `org-headline-done' when `DONE'
>>>  (`org-fontify-done-headline').
>>> 
>>>  I looked at it, following Bastien's hints, but never could make it work.
> 
> http://permalink.gmane.org/gmane.emacs.orgmode/68552
> 
>>> 2. 20130909.1657: Clocktable error with multiple source files from parent 
>>> dir
> 
> http://comments.gmane.org/gmane.emacs.orgmode/76207
> 
>>> 3. 20130912.1455: `org-agenda-sorting-strategy' does not work in `tags-todo'
>>> 
>>>  The following agenda view is supposed to display the tasks by ascending
>>>  DEADLINE timestamp.
>>> 
>>>(add-to-list 'org-agenda-custom-commands
>>> '("B" "Today"
>>>   tags-todo "DEADLINE<=\"\""
>>>   ((org-agenda-overriding-header "Today")
>>>(org-agenda-sorting-strategy '(deadline-up t)
>>> 
>>>  it sorts the list by category, instead!
> 
> http://permalink.gmane.org/gmane.emacs.orgmode/76347
> 
>>> OTOH, you can "delegate" the problem #24 to me.
>>> 
>>> - 20130911.1448: Colored tags generate an error when C-x C-w'ing the agenda
>>> 
>>> I'll try to debug and fix it myself. I'll come back if I don't succeed.
>> 
>> OK, will do that, thank you.
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [Feature Request] Make property-drawers exportable

[Carsten Dominik]

On 25.9.2013, at 11:31, Carsten Dominik  wrote:

> Hi everyone,
> 
> I would like to come back to this issue.
> 
> While I can follow the argumentation that drawers are meta data and that it 
> is really hard for a backend to do something general and correct with them, I 
> am still wondering if it wouldn't be good to have some default way to export 
> them anyway.  I'd be perfectly content to have is such that drawers can be 
> exported as an @example block.  I also think that the export of drawers 
> should definitely be OFF by default.
> 
> Having the default backends allow export of drawers as examples opens the 
> door to use filters to modify it.  This has the advantage that a new backend 
> does not have to be defined.  I am experimenting right now with defining 
> filters with Babel in buffers, and I am finding this a powerful way to tweak 
> the export of an individual file.

P.S. of course there is also the possibility that I could use Babel to define 
or temporarily modify an export backend on the fly - but I have not figured out 
how this might work..



> 
> The reason why I am bringing this up is the following:
> 
> I am reviving the Org Issues file, see the other thread on the mailing list.  
> I would like to be able to export the LOOGBOOK state changes, and these are 
> naturally located in a drawer.
> 
> The problem here is that the export is happening on worg, in an automatic 
> way.  So it is not really an easy option to define a new backend that will be 
> used for just this file, because publishing on Worg uses org-to-html.
> 
> Now, being the person with the keys, I *could*, of course go and define a 
> special backend on Worg that does what I want - but I do also understand the 
> wish expressed by a couple of people in this thread.
> 
> We still have the variable org-export-with-drawers in ox.el.  My proposal 
> would be to set the default to nil, plain and simple, and use a t value to 
> make drawers export as @example.  Safe enough, and easy enough.
> 
> Regards
> 
> - Carsten
> 
> On 17.6.2013, at 21:04, Nicolas Goaziou  wrote:
> 
>> Thorsten Jolitz  writes:
>> 
>>> Nicolas Goaziou  writes:
>> 
 Property drawers are Org meta data, they are not for user's
 cosumption. Though you can export some properties with macros (see
 {{{property{NAME macros).
>>> 
>>> I don't really agree. Property drawers are for meta data used by
>>> Org-mode too, obviously, but they are perfectly suited for meta-data
>>> about the document, as well as those simple data-base features described
>>> in the manual.
>> 
>> It seems I wasn't clear enough. More on this below.
>> 
>>> Why deny Org users the full benefit of these other uses for
>>> property-drawers by denying them the possibility to export their
>>> document meta-data or data-bases?
>> 
>> I don't deny anyone the right code this:
>> 
>> (defun my-latex-property-drawer (drawer contents info)
>>   (concat "\\begin{example}\n"
>>   (org-element-interpret-data drawer)
>>   "\\end{example}"))
>> 
>> (org-export-define-derived-backend 'my-latex 'latex
>>   :translate-alist '((property-drawer . my-latex-property-drawer)))
>> 
>> [...]
>> 
>>> And whats wrong with a simple CD collection database implemented with
>>> property-drawers, as described in the manual? Why shouldn't people be
>>> allowed to export their CD database to some text-formatting backend?
>> 
>> Database example is interesting. My point is that you will never want to
>> dump the whole database in your exported document because Org may fill
>> it with its own meta-data, making the output look like garbage. Also,
>> some backends (ox-icalendar, at least) create properties during export,
>> so you would even get new properties in your output.
>> 
>> It's perfectly fine to export the part of a database you're interested
>> in, like your whole CD collection, but it requires to filter out Org
>> meta-data, and to properly format your own properties. This depends so
>> much on the contents of your database that it is impossible to provide
>> good defaults for it.
>> 
>> Therefore, default export doesn't even try. Instead, tools are provided
>> to access values from your own database (again, macro
>> {{{property(...)}}}) so they can be exported. If you have special needs
>> for your database, just code them and plug them in.
>> 
>> You have a choice.
>> 
>> 
>> Regards,
>> 
>> -- 
>> Nicolas Goaziou
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [Feature Request] Make property-drawers exportable

[Carsten Dominik]

Hi everyone,

I would like to come back to this issue.

While I can follow the argumentation that drawers are meta data and that it is 
really hard for a backend to do something general and correct with them, I am 
still wondering if it wouldn't be good to have some default way to export them 
anyway.  I'd be perfectly content to have is such that drawers can be exported 
as an @example block.  I also think that the export of drawers should 
definitely be OFF by default.

Having the default backends allow export of drawers as examples opens the door 
to use filters to modify it.  This has the advantage that a new backend does 
not have to be defined.  I am experimenting right now with defining filters 
with Babel in buffers, and I am finding this a powerful way to tweak the export 
of an individual file.

The reason why I am bringing this up is the following:

I am reviving the Org Issues file, see the other thread on the mailing list.  I 
would like to be able to export the LOOGBOOK state changes, and these are 
naturally located in a drawer.

The problem here is that the export is happening on worg, in an automatic way.  
So it is not really an easy option to define a new backend that will be used 
for just this file, because publishing on Worg uses org-to-html.

Now, being the person with the keys, I *could*, of course go and define a 
special backend on Worg that does what I want - but I do also understand the 
wish expressed by a couple of people in this thread.

We still have the variable org-export-with-drawers in ox.el.  My proposal would 
be to set the default to nil, plain and simple, and use a t value to make 
drawers export as @example.  Safe enough, and easy enough.

Regards

- Carsten

On 17.6.2013, at 21:04, Nicolas Goaziou  wrote:

> Thorsten Jolitz  writes:
> 
>> Nicolas Goaziou  writes:
> 
>>> Property drawers are Org meta data, they are not for user's
>>> cosumption. Though you can export some properties with macros (see
>>> {{{property{NAME macros).
>> 
>> I don't really agree. Property drawers are for meta data used by
>> Org-mode too, obviously, but they are perfectly suited for meta-data
>> about the document, as well as those simple data-base features described
>> in the manual.
> 
> It seems I wasn't clear enough. More on this below.
> 
>> Why deny Org users the full benefit of these other uses for
>> property-drawers by denying them the possibility to export their
>> document meta-data or data-bases?
> 
> I don't deny anyone the right code this:
> 
>  (defun my-latex-property-drawer (drawer contents info)
>(concat "\\begin{example}\n"
>(org-element-interpret-data drawer)
>"\\end{example}"))
> 
>  (org-export-define-derived-backend 'my-latex 'latex
>:translate-alist '((property-drawer . my-latex-property-drawer)))
> 
> [...]
> 
>> And whats wrong with a simple CD collection database implemented with
>> property-drawers, as described in the manual? Why shouldn't people be
>> allowed to export their CD database to some text-formatting backend?
> 
> Database example is interesting. My point is that you will never want to
> dump the whole database in your exported document because Org may fill
> it with its own meta-data, making the output look like garbage. Also,
> some backends (ox-icalendar, at least) create properties during export,
> so you would even get new properties in your output.
> 
> It's perfectly fine to export the part of a database you're interested
> in, like your whole CD collection, but it requires to filter out Org
> meta-data, and to properly format your own properties. This depends so
> much on the contents of your database that it is impossible to provide
> good defaults for it.
> 
> Therefore, default export doesn't even try. Instead, tools are provided
> to access values from your own database (again, macro
> {{{property(...)}}}) so they can be exported. If you have special needs
> for your database, just code them and plug them in.
> 
> You have a choice.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Org mode issue tracker

[Sebastien Vauban]

Hi Suvayu,

Suvayu Ali wrote:
> On Wed, Sep 25, 2013 at 09:51:20AM +0200, Sebastien Vauban wrote:
>> 
>> The other solution that I'd see would be using Emacs' own bug tracker (the
>> `org' package is already known to them), if that's possible. Anyway, having 
>> the
>> bugs in an Org file seems natural too!
>
> I think this is a great idea.  A combination of an Org file (either
> public or private) and the Emacs bug tracker with Org package tags
> should be able to handle our needs.
>
> I see only one potential problem, is there an easy way to subscribe to
> only a specific package tag on the Emacs bug tracker?  I imagine most
> contributors following Org bugs will not be interested in other Emacs
> bugs.

I don't know. I guess this should be asked directly to them. Indeed, it'd be
good to have a (virtual) newsgroup with only bugs related to `org', like what
exists for Stack Overflow.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [export] Should sidewaystable option automatically add rotating package?

[Rasmus]

Nicolas Girard  writes:

> 2013/9/25 Carsten Dominik :

> I came to think that, having a piece of code that brings
> cross-compatibility between the 3 engines would be of interest to
> people outside of the Org community. But this is not trivial,
> especially if the code has to work with older TeX distributions (a
> reasonable expectation would be that it works with, say, TeXlive 2011
> and TeXlive 2012).

Why 2011?  We also require a recent Emacs with recent Org, or?

> For instance, one difficulty is language specifics. pdflatex has Babel
> ; xelatex has polyglossia ; and lualatex didn't have any equivalent
> package until a recent version of polyglossia that comes with the most
> recent TeX distributions.

babel works with xelatex and lualatex.  I used it for now since
polyglossia does not work with biblatex.

> For these reasons, I would like to submit this question, with my code
> as a starting point, to the tex.stackexchange.com community, so that
> it is peer reviewed and we hopefully get something solid. I'm
> currently working on it and intend to post either today or tomorrow.
> Stay tuned !

The code you use can be greatly simplified by using iftex.  I don't
think \makeatletter\makeatother is necessary at all in this case.

–Rasmus

-- 
Got mashed potatoes. Ain't got no T-Bone. No T-Bone

Re: [O] Org mode issue tracker

[Sebastien Vauban]

Carsten Dominik wrote:
> On 25.9.2013, at 09:51, Sebastien Vauban  wrote:
>> Carsten Dominik wrote:
>>> we do not have an issue tracker for Org.  However, if you
>>> have some time to help, the file with open issues that need
>>> attention can be found here:
>>> 
>>> https://dl.dropboxusercontent.com/u/530458/org-tracker.html
>>> 
>>> Note that I do not enter every issue into this file.  Normally I wait
>>> and see if a report gets addressed on the mailing list, and only
>>> if that does not happen, than I make a note in this file.  I think
>>> this keeps it more manageable for me - an official online bug tracker
>>> would probably quickly fill with many small things we can better
>>> handle on the list.
>>> 
>>> If you feel that this is not going well enough and if I am missing
>>> important reports in this way, let me know and we will find a better
>>> solution.
>>> 
>>> Some of these bugs still need confirmation by a second party,
>>> and patches are always welcome.  If possible, reply in
>>> the original thread, while still mentioning the bug number
>>> in the above link.
>> 
>> The other solution that I'd see would be using Emacs' own bug tracker (the
>> `org' package is already known to them), if that's possible. Anyway, having 
>> the
>> bugs in an Org file seems natural too!
>> 
>> But shouldn't it, maybe, be in a Git project, so that other people can edit 
>> it?
>> 
>> And choosing to have the `Assignee' (or `ASSIGNEE') property be the official
>> Org way to delegate a task to someone would help?
>> 
>> Regarding the list itself, if I may, I would add 3 problems (identified by 
>> the
>> date and time it has been sent on the Org mailing list):
>
> To make my life easier, cold you please provide gmane links?

DONE ;-)  See below.

>> 1. 20130315.1805: Background color reset for links and DONE headlines
>> 
>>   Allow to have more faces than just `org-headline-done' when `DONE'
>>   (`org-fontify-done-headline').
>> 
>>   I looked at it, following Bastien's hints, but never could make it work.

http://permalink.gmane.org/gmane.emacs.orgmode/68552

>> 2. 20130909.1657: Clocktable error with multiple source files from parent dir

http://comments.gmane.org/gmane.emacs.orgmode/76207

>> 3. 20130912.1455: `org-agenda-sorting-strategy' does not work in `tags-todo'
>> 
>>   The following agenda view is supposed to display the tasks by ascending
>>   DEADLINE timestamp.
>> 
>> (add-to-list 'org-agenda-custom-commands
>>  '("B" "Today"
>>tags-todo "DEADLINE<=\"\""
>>((org-agenda-overriding-header "Today")
>> (org-agenda-sorting-strategy '(deadline-up t)
>> 
>>   it sorts the list by category, instead!

http://permalink.gmane.org/gmane.emacs.orgmode/76347

>> OTOH, you can "delegate" the problem #24 to me.
>> 
>> - 20130911.1448: Colored tags generate an error when C-x C-w'ing the agenda
>> 
>>  I'll try to debug and fix it myself. I'll come back if I don't succeed.
>
> OK, will do that, thank you.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Org mode issue tracker

[Carsten Dominik]

On 25.9.2013, at 08:43, Carsten Dominik  wrote:

> Hi everyone,
> 
> we do not have an issue tracker for Org.  However, if you
> have some time to help, the file with open issues that need
> attention can be found here:
> 
> https://dl.dropboxusercontent.com/u/530458/org-tracker.html

I have moved the tracker to Worg, discarding the old tracker file that was at 
that location.

http://orgmode.org/worg/org-issues.html

- Carsten

> 
> Note that I do not enter every issue into this file.  Normally I wait
> and see if a report gets addressed on the mailing list, and only
> if that does not happen, than I make a note in this file.  I think
> this keeps it more manageable for me - an official online bug tracker
> would probably quickly fill with many small things we can better
> handle on the list.
> 
> If you feel that this is not going well enough and if I am missing
> important reports in this way, let me know and we will find a better
> solution.
> 
> Some of these bugs still need confirmation by a second party,
> and patches are always welcome.  If possible, reply in
> the original thread, while still mentioning the bug number
> in the above link.
> 
> Regards
> 
> - Carsten



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [export] Should sidewaystable option automatically add rotating package?

[Carsten Dominik]

Excellent, I'll wait for your further input.

Thanks Nicolas!

- Carsten

On 25.9.2013, at 09:45, Nicolas Girard  wrote:

> 2013/9/25 Carsten Dominik :
>> 
>> On 19.9.2013, at 11:38, Nicolas Girard  wrote:
>> 
>>> I actually have some working code that does this. It lies in a file I
>>> named 'minimal.tex', which I include into all my latex code using
>>> \input{minimal}\makeatletter
>> 
>> Hi Nicolas,
>> 
>> of I were to include this code not via \input, but directly, somewhere in 
>> the header,
>> is there something special with makeatletter/makeatother that I have to do?
>> 
> 
> Good morning Carsten,
> 
> Despite being silent, I didn't forget about this thread ;-)
> 
> I came to think that, having a piece of code that brings
> cross-compatibility between the 3 engines would be of interest to
> people outside of the Org community. But this is not trivial,
> especially if the code has to work with older TeX distributions (a
> reasonable expectation would be that it works with, say, TeXlive 2011
> and TeXlive 2012).
> 
> For instance, one difficulty is language specifics. pdflatex has Babel
> ; xelatex has polyglossia ; and lualatex didn't have any equivalent
> package until a recent version of polyglossia that comes with the most
> recent TeX distributions.
> 
> For these reasons, I would like to submit this question, with my code
> as a starting point, to the tex.stackexchange.com community, so that
> it is peer reviewed and we hopefully get something solid. I'm
> currently working on it and intend to post either today or tomorrow.
> Stay tuned !
> 
> Cheers,
> Nicolas



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Org mode issue tracker

[Suvayu Ali]

On Wed, Sep 25, 2013 at 09:51:20AM +0200, Sebastien Vauban wrote:
> 
> The other solution that I'd see would be using Emacs' own bug tracker (the
> `org' package is already known to them), if that's possible. Anyway, having 
> the
> bugs in an Org file seems natural too!

I think this is a great idea.  A combination of an Org file (either
public or private) and the Emacs bug tracker with Org package tags
should be able to handle our needs.

I see only one potential problem, is there an easy way to subscribe to
only a specific package tag on the Emacs bug tracker?  I imagine most
contributors following Org bugs will not be interested in other Emacs
bugs.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Org mode issue tracker

[Carsten Dominik]

On 25.9.2013, at 09:51, Sebastien Vauban  wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>> we do not have an issue tracker for Org.  However, if you
>> have some time to help, the file with open issues that need
>> attention can be found here:
>> 
>> https://dl.dropboxusercontent.com/u/530458/org-tracker.html
>> 
>> Note that I do not enter every issue into this file.  Normally I wait
>> and see if a report gets addressed on the mailing list, and only
>> if that does not happen, than I make a note in this file.  I think
>> this keeps it more manageable for me - an official online bug tracker
>> would probably quickly fill with many small things we can better
>> handle on the list.
>> 
>> If you feel that this is not going well enough and if I am missing
>> important reports in this way, let me know and we will find a better
>> solution.
>> 
>> Some of these bugs still need confirmation by a second party,
>> and patches are always welcome.  If possible, reply in
>> the original thread, while still mentioning the bug number
>> in the above link.
> 
> The other solution that I'd see would be using Emacs' own bug tracker (the
> `org' package is already known to them), if that's possible. Anyway, having 
> the
> bugs in an Org file seems natural too!
> 
> But shouldn't it, maybe, be in a Git project, so that other people can edit 
> it?
> 
> And choosing to have the `Assignee' (or `ASSIGNEE') property be the official
> Org way to delegate a task to someone would help?
> 
> Regarding the list itself, if I may, I would add 3 problems (identified by the
> date and time it has been sent on the Org mailing list):

To make my life easier, cold you please provide gmane links?

> 
> 1. 20130315.1805: Background color reset for links and DONE headlines
> 
>   Allow to have more faces than just `org-headline-done' when `DONE'
>   (`org-fontify-done-headline').
> 
>   I looked at it, following Bastien's hints, but never could make it work.
> 
> 2. 20130909.1657: Clocktable error with multiple source files from parent dir
> 
> 3. 20130912.1455: `org-agenda-sorting-strategy' does not work in `tags-todo'
> 
>   The following agenda view is supposed to display the tasks by ascending
>   DEADLINE timestamp.
> 
> (add-to-list 'org-agenda-custom-commands
>  '("B" "Today"
>tags-todo "DEADLINE<=\"\""
>((org-agenda-overriding-header "Today")
> (org-agenda-sorting-strategy '(deadline-up t)
> 
>   it sorts the list by category, instead!
> 
> OTOH, you can "delegate" the problem #24 to me.
> 
> - 20130911.1448: Colored tags generate an error when C-x C-w'ing the agenda
> 
>  I'll try to debug and fix it myself. I'll come back if I don't succeed.

OK, will do that, thank you.

- Carsten

> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Org mode issue tracker

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> we do not have an issue tracker for Org.  However, if you
> have some time to help, the file with open issues that need
> attention can be found here:
>
> https://dl.dropboxusercontent.com/u/530458/org-tracker.html
>
> Note that I do not enter every issue into this file.  Normally I wait
> and see if a report gets addressed on the mailing list, and only
> if that does not happen, than I make a note in this file.  I think
> this keeps it more manageable for me - an official online bug tracker
> would probably quickly fill with many small things we can better
> handle on the list.
>
> If you feel that this is not going well enough and if I am missing
> important reports in this way, let me know and we will find a better
> solution.
>
> Some of these bugs still need confirmation by a second party,
> and patches are always welcome.  If possible, reply in
> the original thread, while still mentioning the bug number
> in the above link.

The other solution that I'd see would be using Emacs' own bug tracker (the
`org' package is already known to them), if that's possible. Anyway, having the
bugs in an Org file seems natural too!

But shouldn't it, maybe, be in a Git project, so that other people can edit it?

And choosing to have the `Assignee' (or `ASSIGNEE') property be the official
Org way to delegate a task to someone would help?

Regarding the list itself, if I may, I would add 3 problems (identified by the
date and time it has been sent on the Org mailing list):

1. 20130315.1805: Background color reset for links and DONE headlines

   Allow to have more faces than just `org-headline-done' when `DONE'
   (`org-fontify-done-headline').

   I looked at it, following Bastien's hints, but never could make it work.

2. 20130909.1657: Clocktable error with multiple source files from parent dir

3. 20130912.1455: `org-agenda-sorting-strategy' does not work in `tags-todo'

   The following agenda view is supposed to display the tasks by ascending
   DEADLINE timestamp.

 (add-to-list 'org-agenda-custom-commands
  '("B" "Today"
tags-todo "DEADLINE<=\"\""
((org-agenda-overriding-header "Today")
 (org-agenda-sorting-strategy '(deadline-up t)

   it sorts the list by category, instead!

OTOH, you can "delegate" the problem #24 to me.

- 20130911.1448: Colored tags generate an error when C-x C-w'ing the agenda

  I'll try to debug and fix it myself. I'll come back if I don't succeed.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [export] Should sidewaystable option automatically add rotating package?

[Nicolas Girard]

2013/9/25 Carsten Dominik :
>
> On 19.9.2013, at 11:38, Nicolas Girard  wrote:
>
>> I actually have some working code that does this. It lies in a file I
>> named 'minimal.tex', which I include into all my latex code using
>>  \input{minimal}\makeatletter
>
> Hi Nicolas,
>
> of I were to include this code not via \input, but directly, somewhere in the 
> header,
> is there something special with makeatletter/makeatother that I have to do?
>

Good morning Carsten,

Despite being silent, I didn't forget about this thread ;-)

I came to think that, having a piece of code that brings
cross-compatibility between the 3 engines would be of interest to
people outside of the Org community. But this is not trivial,
especially if the code has to work with older TeX distributions (a
reasonable expectation would be that it works with, say, TeXlive 2011
and TeXlive 2012).

For instance, one difficulty is language specifics. pdflatex has Babel
; xelatex has polyglossia ; and lualatex didn't have any equivalent
package until a recent version of polyglossia that comes with the most
recent TeX distributions.

For these reasons, I would like to submit this question, with my code
as a starting point, to the tex.stackexchange.com community, so that
it is peer reviewed and we hopefully get something solid. I'm
currently working on it and intend to post either today or tomorrow.
Stay tuned !

Cheers,
Nicolas

Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

Carsten Dominik  writes:

> On 25.9.2013, at 08:53, Rainer M Krug  wrote:
>
>> "Sebastien Vauban" 
>> writes:
>> 
>>> Hi Carsten,
>>> 
>>> Carsten Dominik wrote:
 On 24.9.2013, at 18:17, Sebastien Vauban  wrote:
> Carsten Dominik wrote:
>> On 23.9.2013, at 09:40, Rainer M Krug  wrote:
>>> 
>>> When starting to edit a code block via C-c ' everything works as 
>>> expected
>>> and the code block is highlighted and an indirect buffer is opened.
>>> 
>>> When I click into the highlighted block, I an "send" to the indirect 
>>> buffer.
>>> This behavior changes, after saving with C-s, even when nothing has been
>>> edited: the area in the original org file looses its magic, and looks 
>>> normal
>>> again and can also be edited!
>>> 
>>> The indirect buffer stays functional and, upon close via C-c ' saves the
>>> changes into the original buffer and *overwrites* changes done in this 
>>> block
>>> in the org document.
>> 
>> This is a bug which is difficult to fix in all generality. What should 
>> really
>> happen is that the text in the original buffer is made read-only. But so 
>> far
>> this does not happen in our implementation (due to Dan Davison IIRC). The
>> reason for this is that read-only text properties left by accident in a
>> buffer are difficult to get rid of.
>> 
>> There are many things the user could go back and screw up the original.
>> That's why Org choses to protect with highlighting with an overlay. Note 
>> that
>> this is not a protection against editing, but it is a visual warning.
> 
> I never knew that "your" goal was to make the code block read-only in the 
> Org
> buffer. Note that I would be really opposed to such a change. Editing 
> code in
> the prose would really become a pain to me -- please know that I NEVER 
> use the
> indirect buffer.
 
 I only mean while there is a special buffer also editing this block!
>>> 
>>> Pfff!  I'm relieved -- I should have understood it ;-)
>> 
>> While we are at editing code blocks inline (I also do this quite often).
>> 
>> This might have been asked before, but in code blocks we have
>> 
>> - syntax highlighting
>> - indenting using the code block language settings
>> 
>> but would it be possible to have, when the cursor is in a code block,
>> the menus and shortcuts for the language mode enabled, i.e. complete
>> support for editing the code block language, as in the special buffer,
>> but inline in org? Evaluationg single lines of code directly from the
>> code block in org would be *brilliant*.
>
> This is very complicated, because such functionality needs
> the entire environment of a mode.  I think there are some solutions
> which allow multiple major modes - but I don't think we will go
> there with Org.

This is definitely not an easy task, but which I think would be an very
useful feature, making the work-flow of using embedded code much faster.

>
> However, I think this is really a question to Eric Schulte (in CC).

Would be great, if there is would be a way of implementing this in the
medium future.

Cheers,

Rainer

>
> - Carsten
>
>> 
>> Cheers,
>> 
>> Rainer
>> 
>>> 
>>> Best regards,
>>>  Seb
>> <#secure method=pgpmime mode=sign>
>> 
>> -- 
>> Rainer M. Krug
>> 
>> email: RMKruggmailcom
>> 
>> 
>


-- 
Rainer M. Krug

email: RMKruggmailcom


pgpFHaWFRygXe.pgp
Description: PGP signature

Re: [O] Spurious exporting of text before first header

[Sebastien Vauban]

Hi François,

François Pinard wrote:
> This is an old annoyance of the Org exporter, yet I'm not sure what
> would be its best resolution.
>
> Whenever I use :export: tags on headers within an Org file, I expect
> only those headers and their contents to be exported (to HTML in my
> case), and almost nothing else, which I then consider private.
>
> However, if I have text and other contents prior to the first header of
> a file, those contents are indeed exported, while I would prefer not.
>
> Of course, #+TITLE and some other directives prior to the first header
> should be honored for their effect.  One might surely debate on the best
> way to handle #+INCLUDE directive.
>
> I wish the above comments might generate either a correction in Org, or
> an advice for me! :-)
>
> P.S. Some might suggest me that I avoid text prior to the first header.
> Surely, I have hundreds of Org files and for them all, have some
> personal conventions for their format and structure.  For regularity
> reasons, I would much like to continue having private initial text.

If you like text without initial heading in the exported file, but don't mind
adding an heading in the Org buffer, you could add this:

--8<---cut here---start->8---
* Initial text :ignoreheading:
--8<---cut here---end--->8---

and get what you want in the exported file.

I thought that the filter to ignore the heading only was already in Org, but a
quick test with the ASCII backend makes me thing it isn't. Anyway, you can find
recent posts on this.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Question: How to suppress the generation of toc in html export?

[Carsten Dominik]

On 25.9.2013, at 09:25, Daniel Thom  wrote:

> "maybe just put a 
> 
> ,-
> | #+OPTIONS toc:nil
> `-

Colon missing after OPTIONS.

- Carsten

> 
> before the first headline of your org file?"
> 
> No, that did not help. In the html output there is a toc again.
> Besides i have a lot export projects like pdf and odt and for that i want a 
> toc.
> Only the html output should be without a toc.
> 
> for jekyll use i need to set the first lines of the html output. 
> 
> Another Idea?
> 
> -- 
> Gru�
> Daniel
> 
> http://netbunker.de
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Org mode issue tracker

[Carsten Dominik]

On 25.9.2013, at 09:28, Christian Moe  wrote:

> 
> Hi,
> 
> I was going to ask about this.
> 
> The website actually does direct people to a collaborative issue tracker
> on Worg:
> 
> http://orgmode.org/worg/org-issues.html

Ha, I completely forgot about this one, and it seems
to be entirely out of date.  And I don't think it ever *really* worked.
For now I am comfortable to do most of the tracking in the mailing list.
Lets trash this old list and use the new one for now, while we think about
a realistic system.

- Carsten


replace it with my new list.

> 
> As outlined there, the idea was that the maintainer would add issues
> from the mailing list, but others were welcome to modify the entries,
> e.g. to assign an issue to themselves.
> 
> It's a nice idea, but it doesn't seem to have been regularly used since
> 2011 or so (?).
> 
> Yours,
> Christian
> 
> Carsten Dominik writes:
> 
>> Hi everyone,
>> 
>> we do not have an issue tracker for Org.  However, if you
>> have some time to help, the file with open issues that need
>> attention can be found here:
>> 
>> https://dl.dropboxusercontent.com/u/530458/org-tracker.html
>> 
>> (...) I think
>> this keeps it more manageable for me - an official online bug tracker
>> would probably quickly fill with many small things we can better
>> handle on the list.
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

Carsten Dominik  writes:

> On 25.9.2013, at 08:48, Rainer M Krug  wrote:
>
>> Carsten Dominik  writes:
>> 
>>> Hi Rainer, hi Carsten,
>>> 
>>> it does not get lost - it is in my queue.  As are, unfortunately,
>>> another 35 threads with possible bugs.  Help is definitely wanted.
>> 
>> That's what I was looking for - confirmation that is in somebodys
>> processing queue. Thanks Carsten.
>> 
>> Unfortunately I can't hel as I have barely the elisp knowledge to
>> maintain my .emacs file.
>> 
>>> 
>>> Please see below for my comments and a possible fix.
>>> 
>>> On 23.9.2013, at 09:40, Rainer M Krug  wrote:
>>> 
 I just resend this bug report which has been confirmed by Ista Zahn.
 
 Updated via git ust now:
 
 Org-mode version 8.2 (release_8.2-14-ge5f16b @
 /Users/rainerkrug/.emacs.d/org-mode/lisp/)
 
 
 When starting to edit a code block via C-c ' everything works as expected
 and the code block is highlighted and an indirect buffer is opened.
 
 When I click into the highlighted block, I an "send" to the indirect
 buffer. This behavior changes, after saving with C-s, even when nothing
 has been edited: the area in the original org file looses its magic, and
 looks normal again and can also be edited! 
 
 The indirect buffer stays functional and, upon close via C-c ' saves the
 changes into the original buffer and *overwrites* changes done in this
 block in the org document.
>>> 
>>> This is a bug which is difficult to fix in all generality.  What
>>> should really happen is that the text in the original buffer is made
>>> read-only.  
>> 
>> Yup - exactly. That would be the best solution.
>> 
>>> But so far this does not happen in our implementation (due
>>> to Dan Davison IIRC).  The reason for this is that read-only text
>>> properties left by accident in a buffer are difficult to get rid of.
>>> 
>>> There are many things the user could go back and screw up the
>>> original.  That's why Org choses to protect with highlighting with an
>>> overlay.  Note that this is not a protection against editing, but it
>>> is a visual warning.
>> 
>> Possibly because I am using the mouse most of the time to navigate in
>> text and select buffers, I did not realize this.
>> 
>>> 
>>> However, what happens during saving is indeed a problem - the overlay
>>> gets lost (not really, it gets squeezed to zero by first removing the
>>> source code and then inserting the modified version).
>>> 
>>> Could you please try this patch and test it to see if it is stable and
>>> does the right thing?
>> 
>> Tried briefly and it seems to work:
>> 
>> 1) the visual overlay stays there upon C-x s from indirect buffer
>> 
>> 2) If I click with the mouse into it, I am redirected to the indirect
>> buffer (correct terminology here?)
>> 
>> Let me know when you pushed it to git, than I can upgrade again.
>
> I pushed this fix to maint and master.


Thanks,

Rainer

>
> - Carsten
>
>> 
>> Thanks,
>> 
>> Rainer
>> 
>>> 
>>> Thank you.
>>> 
>>> - Carsten
>>> 
>>> diff --git a/lisp/org-src.el b/lisp/org-src.el
>>> index 0f88174..062d2d7 100644
>>> --- a/lisp/org-src.el
>>> +++ b/lisp/org-src.el
>>> @@ -757,6 +757,8 @@ with \",*\", \",#+\", \",,*\" and \",,#+\"."
>>> (delete-region beg (max beg end))
>>> (unless (string-match "\\`[ \t]*\\'" code)
>>>   (insert code))
>>> +   ;; Make sure the overlay stays in place
>>> +   (when (eq context 'save) (move-overlay ovl beg (point)))
>>> (goto-char beg)
>>> (if single (just-one-space
>>> (if (memq t (mapcar (lambda (overlay)
>>> 
>>> 
>> <#secure method=pgpmime mode=sign>
>> 
>> -- 
>> Rainer M. Krug
>> 
>> email: RMKruggmailcom
>> 
>> 
>
<#secure method=pgpmime mode=sign>

-- 
Rainer M. Krug

email: RMKruggmailcom

[O] Question: How to suppress the generation of toc in html export?

[Daniel Thom]

"maybe just put a 

,-
| #+OPTIONS toc:nil
`-

before the first headline of your org file?"

No, that did not help. In the html output there is a toc again.
Besides i have a lot export projects like pdf and odt and for that i want a toc.
Only the html output should be without a toc.

for jekyll use i need to set the first lines of the html output. 

Another Idea?

-- 
Gru�
Daniel

http://netbunker.de

Re: [O] Org mode issue tracker

[Christian Moe]

Hi,

I was going to ask about this.

The website actually does direct people to a collaborative issue tracker
on Worg:

http://orgmode.org/worg/org-issues.html

As outlined there, the idea was that the maintainer would add issues
from the mailing list, but others were welcome to modify the entries,
e.g. to assign an issue to themselves.

It's a nice idea, but it doesn't seem to have been regularly used since
2011 or so (?).

Yours,
Christian

Carsten Dominik writes:

> Hi everyone,
>
> we do not have an issue tracker for Org.  However, if you
> have some time to help, the file with open issues that need
> attention can be found here:
>
> https://dl.dropboxusercontent.com/u/530458/org-tracker.html
>
> (...) I think
> this keeps it more manageable for me - an official online bug tracker
> would probably quickly fill with many small things we can better
> handle on the list.

Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer

[Carsten Dominik]

On 25.9.2013, at 08:48, Rainer M Krug  wrote:

> Carsten Dominik  writes:
> 
>> Hi Rainer, hi Carsten,
>> 
>> it does not get lost - it is in my queue.  As are, unfortunately,
>> another 35 threads with possible bugs.  Help is definitely wanted.
> 
> That's what I was looking for - confirmation that is in somebodys
> processing queue. Thanks Carsten.
> 
> Unfortunately I can't hel as I have barely the elisp knowledge to
> maintain my .emacs file.
> 
>> 
>> Please see below for my comments and a possible fix.
>> 
>> On 23.9.2013, at 09:40, Rainer M Krug  wrote:
>> 
>>> I just resend this bug report which has been confirmed by Ista Zahn.
>>> 
>>> Updated via git ust now:
>>> 
>>> Org-mode version 8.2 (release_8.2-14-ge5f16b @
>>> /Users/rainerkrug/.emacs.d/org-mode/lisp/)
>>> 
>>> 
>>> When starting to edit a code block via C-c ' everything works as expected
>>> and the code block is highlighted and an indirect buffer is opened.
>>> 
>>> When I click into the highlighted block, I an "send" to the indirect
>>> buffer. This behavior changes, after saving with C-s, even when nothing
>>> has been edited: the area in the original org file looses its magic, and
>>> looks normal again and can also be edited! 
>>> 
>>> The indirect buffer stays functional and, upon close via C-c ' saves the
>>> changes into the original buffer and *overwrites* changes done in this
>>> block in the org document.
>> 
>> This is a bug which is difficult to fix in all generality.  What
>> should really happen is that the text in the original buffer is made
>> read-only.  
> 
> Yup - exactly. That would be the best solution.
> 
>> But so far this does not happen in our implementation (due
>> to Dan Davison IIRC).  The reason for this is that read-only text
>> properties left by accident in a buffer are difficult to get rid of.
>> 
>> There are many things the user could go back and screw up the
>> original.  That's why Org choses to protect with highlighting with an
>> overlay.  Note that this is not a protection against editing, but it
>> is a visual warning.
> 
> Possibly because I am using the mouse most of the time to navigate in
> text and select buffers, I did not realize this.
> 
>> 
>> However, what happens during saving is indeed a problem - the overlay
>> gets lost (not really, it gets squeezed to zero by first removing the
>> source code and then inserting the modified version).
>> 
>> Could you please try this patch and test it to see if it is stable and
>> does the right thing?
> 
> Tried briefly and it seems to work:
> 
> 1) the visual overlay stays there upon C-x s from indirect buffer
> 
> 2) If I click with the mouse into it, I am redirected to the indirect
> buffer (correct terminology here?)
> 
> Let me know when you pushed it to git, than I can upgrade again.

I pushed this fix to maint and master.

- Carsten

> 
> Thanks,
> 
> Rainer
> 
>> 
>> Thank you.
>> 
>> - Carsten
>> 
>> diff --git a/lisp/org-src.el b/lisp/org-src.el
>> index 0f88174..062d2d7 100644
>> --- a/lisp/org-src.el
>> +++ b/lisp/org-src.el
>> @@ -757,6 +757,8 @@ with \",*\", \",#+\", \",,*\" and \",,#+\"."
>>  (delete-region beg (max beg end))
>>  (unless (string-match "\\`[ \t]*\\'" code)
>>(insert code))
>> +;; Make sure the overlay stays in place
>> +(when (eq context 'save) (move-overlay ovl beg (point)))
>>  (goto-char beg)
>>  (if single (just-one-space
>> (if (memq t (mapcar (lambda (overlay)
>> 
>> 
> <#secure method=pgpmime mode=sign>
> 
> -- 
> Rainer M. Krug
> 
> email: RMKruggmailcom
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer

[Carsten Dominik]

On 25.9.2013, at 08:53, Rainer M Krug  wrote:

> "Sebastien Vauban" 
> writes:
> 
>> Hi Carsten,
>> 
>> Carsten Dominik wrote:
>>> On 24.9.2013, at 18:17, Sebastien Vauban  wrote:
 Carsten Dominik wrote:
> On 23.9.2013, at 09:40, Rainer M Krug  wrote:
>> 
>> When starting to edit a code block via C-c ' everything works as expected
>> and the code block is highlighted and an indirect buffer is opened.
>> 
>> When I click into the highlighted block, I an "send" to the indirect 
>> buffer.
>> This behavior changes, after saving with C-s, even when nothing has been
>> edited: the area in the original org file looses its magic, and looks 
>> normal
>> again and can also be edited!
>> 
>> The indirect buffer stays functional and, upon close via C-c ' saves the
>> changes into the original buffer and *overwrites* changes done in this 
>> block
>> in the org document.
> 
> This is a bug which is difficult to fix in all generality. What should 
> really
> happen is that the text in the original buffer is made read-only. But so 
> far
> this does not happen in our implementation (due to Dan Davison IIRC). The
> reason for this is that read-only text properties left by accident in a
> buffer are difficult to get rid of.
> 
> There are many things the user could go back and screw up the original.
> That's why Org choses to protect with highlighting with an overlay. Note 
> that
> this is not a protection against editing, but it is a visual warning.
 
 I never knew that "your" goal was to make the code block read-only in the 
 Org
 buffer. Note that I would be really opposed to such a change. Editing code 
 in
 the prose would really become a pain to me -- please know that I NEVER use 
 the
 indirect buffer.
>>> 
>>> I only mean while there is a special buffer also editing this block!
>> 
>> Pfff!  I'm relieved -- I should have understood it ;-)
> 
> While we are at editing code blocks inline (I also do this quite often).
> 
> This might have been asked before, but in code blocks we have
> 
> - syntax highlighting
> - indenting using the code block language settings
> 
> but would it be possible to have, when the cursor is in a code block,
> the menus and shortcuts for the language mode enabled, i.e. complete
> support for editing the code block language, as in the special buffer,
> but inline in org? Evaluationg single lines of code directly from the
> code block in org would be *brilliant*.

This is very complicated, because such functionality needs
the entire environment of a mode.  I think there are some solutions
which allow multiple major modes - but I don't think we will go
there with Org.

However, I think this is really a question to Eric Schulte (in CC).

- Carsten

> 
> Cheers,
> 
> Rainer
> 
>> 
>> Best regards,
>>  Seb
> <#secure method=pgpmime mode=sign>
> 
> -- 
> Rainer M. Krug
> 
> email: RMKruggmailcom
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [export] Should sidewaystable option automatically add rotating package?

[Carsten Dominik]

On 19.9.2013, at 11:38, Nicolas Girard  wrote:

> 2013/9/19 Carsten Dominik :
>> 
>> On 19.9.2013, at 00:21, Rasmus  wrote:
>> 
>>> So what would the goal be?  To make it compatible with XeLaTeX and
>>> LuaLaTeX out of the box?
>> 
>> Yes, this is what I mean.  I would be happy to have some clever line in 
>> there that would do the right thing for variants of LaTeX.  THis is also 
>> what I mean by "all cases".
> 
> 
> Hi all,
> I actually have some working code that does this. It lies in a file I
> named 'minimal.tex', which I include into all my latex code using
>  \input{minimal}\makeatletter

Hi Nicolas,

of I were to include this code not via \input, but directly, somewhere in the 
header,
is there something special with makeatletter/makeatother that I have to do?

Thanks

- Carsten

> The code allows me to compile my documents using pdflatex, lualatex or 
> xelatex.
> Please find attached the relevant part of my 'minimal.tex' file.
> Cheers
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail