[O] Mobile org - add new items to org file

[Chris Henderson]

My org file on my computer is gtd.org which has 3 top level headings: *
Tasks, * Projects and * Read and Review.

If I add any entry to mobile org, sync it via dropbox and do a
org-mobile-pull from my computer, the new entries go to a file called
flagged.org. Is there any way to make the new entries go to my gtd.org file
instead? Also: would it be possible to define where in gtd.org file the new
entries should go, like some new entries should go under Tasks and some
should go under Projects.

Thanks.

Re: [O] How do I insert a literal '|' to a table in org-mode?

[Marcin Borkowski]

Dnia 2013-10-22, o godz. 07:54:35
b...@pku.edu.cn napisał(a):

> Is that possible?
> 

What about

\vert

or

\vert{}

(see section "The built-in table editor" in the manual, look for the
footnote)?

Hth,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] Bug: verbatim export of python code block with numpy array returns wrong value [8.2.1 (8.2.1-10-g9c1ef6-elpaplus @ /Users/sbagley/Dropbox/emacsd/elpa/org-plus-contrib-20131014/)]

[Eric Schulte]

Hi Steve,

Is this a Python problem or is it numpy specific?

Is repr() a numpy or a Python function i.e., could it replace str() in
every Python code block or only when numpy is loaded?

Thanks,

Steven Bagley  writes:

> The following file contents, when exported (to HTML or pdf), produce
> incorrect output:
> #+PROPERTY: header-args:python :session "*Python*"
> #+PROPERTY: exports both
> #+PROPERTY: results value verbatim
> #+BEGIN_SRC python
> import numpy as np
> np.array([1, 2, 3])
> #+END_SRC
>
> The resulting value block contains [1 2 3], which is not the print
> representation of that numpy array. I suspect the problem arises in
> ob-python.el from the use of str() instead of repr(). Thanks.
> --Steve
>
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
>
>  http://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org-mode mailing list.
> 
>
>
>
> Emacs  : GNU Emacs 24.3.1 (x86_64-apple-darwin11.4.2, Carbon Version
> 1.6.0 AppKit 1138.51)
>  of 2013-09-24 on Yukikaze.local
> Package: Org-mode version 8.2.1 (8.2.1-10-g9c1ef6-elpaplus @
> /Users/sbagley/Dropbox/emacsd/elpa/org-plus-contrib-20131014/)
>

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

Re: [O] Create sub-directories and files from within org

[John Kitchin]

You can do something like this:

#+BEGIN_SRC emacs-lisp
(defun make-project-dir-from-heading ()
  (interactive)
  (save-restriction
(org-narrow-to-subtree)
(let ((heading-title (nth 4 (org-heading-components
  (make-directory heading-title t)
  (goto-char (point-max))
  (insert (format "[[file:%s]]" heading-title)
#+END_SRC

* test-dir

some stuff

[[file:test-dir]]
* next-project


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



On Mon, Oct 21, 2013 at 1:39 PM, Skip Collins wrote:

> On Sun, Oct 20, 2013 at 12:58 PM, John Kitchin 
> wrote:
> >
> > I don't understand what you are trying to do here. you could write a lisp
> > function that you run in the ** project name heading that creates a
> directory
> > by that name. But what would the txt files in that directory be?
>
> I requested something like this functionality some time ago but never
> found an answer. I create new projects in projects.org, via capture or
> direct editing. Each project is a top-level heading that may sometimes
> contain sub-headings, todos, etc. Most often it remains a simple
> top-level heading containing a drawer but no body or subheadings. It
> takes one of the following states: PROJ, DONE, CANCELED, or DORMANT. I
> have several agenda views that track active projects (i.e. not done,
> not canceled, and not dormant), and other tag attributes (personal,
> professional, ...). I use a set of optional tags to track where
> project data is kept: :org:, :computer:, :email:, :file:, :binder:,
> etc. Many projects have the :computer: tag and a corresponding folder
> on my hard drive with various file types stored there including txt,
> docx, org, pdf, jpeg, etc. I would very much like a way to quickly
> create that folder with the unique project name that I assign in the
> top-level heading. It would be super nice if this automagic folder
> creation feature also creates a link to the folder inside my
> projects.org file.
>

[O] right-clicking on org-links

[John Kitchin]

Hi everyone,

I was playing around with being able to get a link action to be different
with a left mouse click and right mouse click. I had some moderate success
which is outlined here:

http://jkitchin.github.io/blog/2013/10/21/Enabling-right-clicks-in-org-mode-links/

On my laptop, I can only get mouse-2 and mouse-3 clicks, no mouse-1 clicks
for some reason, and no modified clicks, e.g. alt-mouse-1. Still, it is
possible to get at least two different clicks! I thought I would share it
in case anyone else wants different click behavior like that too. And in
case anyone has ideas on how to get modified clicks.

 Best wishes,

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

[O] How do I insert a literal '|' to a table in org-mode?

[bsun]

Is that possible?

[O] Ox-HTML hover for certain languages

[R. Michael Weylandt]

Around line 270 of Ox-html.el, there's CSS which gives certain code blocks in 
the resulting HTML a hover-over window saying what language they encode. Not 
all Babel-supported languages appear however: is there any reason for this? 
(E.g. perl is hard-coded but no python)

I suppose one could pull all the sources from the #+BEGIN_SRC XYZ blocks and 
generate this on demand, using a lookup table for known languages and a basic 
capitalization scheme for unknown languages. 

I'm not much of an elisp user, but would be happy to try my hand at a patch if 
this would be of interest. 

Michael

Re: [O] Org-mode and continuing BBDB compatibility

[Nick Dokos]

Christopher Culver  writes:

> I am using org-mode version 20131021 and the latest checkout of the
> bbdb3 git repository. Although I have the following lines in my main
> .org file:
>
> * Anniversaries
>:PROPERTIES:
>:CATEGORY: Anniv
>:END:
>   %%(org-bbdb-anniversaries)
>
> I do not see anniversaries from my .bbdb file in the agenda. I know that
> some work was done in the past with making org-mode compatible with
> bbdb3, but are the two projects no longer compatible, or do I probably
> have some other problem on my end?
>

I believe the %% construct is recognized only at the beginning of a
line: try deleting the white space in front.

Nick

Re: [O] org-mode based groupware wiki

[Torsten Wagner]

Dear Eric,

thanks for the reply.

>> Now I was able to test both gollumn and org-ehtml it puts me into a dilemma.
>>
>
> Multiple viable options for Org-mode wikis is a great problem to have.

Indeed it is as usual with FOSS all those pesty options to choice
from. Why couldn't I just trough my money to multi-billion dollar
companies and use whatever the selling department thought would be
best for me. Silly me ;)

> See the "Integrating with version control" section of the org-ehtml
> README [1].  It provides VC integration with just a couple of lines of
> Emacs Lisp which could be added to the webserver's Emacs config.

I didn't test this yet, but read about it. I will give it a try again.

>> Gollumn itself seems to run on the shoulder of giants and keep itself
>> rather small.
>
> Org-ehtml is itself just a tiny hack which (I think) neatly combines the
> power of the new Org export system, and the power of Elnode running on
> top of a full fledged Emacs instance.  Org-ehtml is more than two orders
> of magnitude smaller than gollum (judging by compressed source code).

Well indeed this was a stupid comparison. Sure org-ehtml is even
smaller and stands on the shoulder giants too, namely of org-mode and
emacs

> Understood.  I hope I haven't wasted your time and I appreciated that
> you got org-ehtml running.  Gollum is a very mature option, and is
> probably your best bet unless you fall into one of the following.

Wasted my time?! ;) Are you kidding me. It was very informative and
fun. Seriously, I always enjoy having org-babel or in this case e-html
related problems, just for the joy I have to talk too you ;)
There is still no decision made yet and I guess it is even not a time
critical decision. Since both systems use org-mode files I could
easily switch between them any time later.

> 1. need more esoteric features of Org-mode or
I frighten looking at the feature test from Karl Voit
(https://github.com/novoid/github-orgmode-tests), the features need
not to be sooo esoteric at all.

> 2. you like the idea of being able to run arbitrary Emacs Lisp as part
>of the editing process or
Yes you are right, thinking about, the advantage would be that I could
use all org-mode related code and do not need to reimplement it in any
other language. E.g., one could get a pretty printed table in text
form easily calling org-table-align, or convert copy and pasted CSV
data into a table calling org-table-convert. However, that would
require an extension of the current web-based editor.

> 3. (like me) you don't have ruby installed on your system and a ruby web
>server seems like a lot of bloat for a wiki
Here I would need to give gollumn the credit that you can use another
web server as well e.g. apache should work.

> The reason Gollum is so much larger is because it has a large team of
> people adding the many handlers for edge cases and extra bells and
> whistles which make for a robust tool.

Sure, and please understand that I do not want to compare them
one-by-one. It wasn't my intention to do any ranking. Just looking for
the best solution for my task. If a 5-liner bash script from 1995
could do what I want I would be equally happy too ;)

> My goal with org-ehtml was to produce a tiny working and (most
> importantly) easily hackable core.  I don't have time to really flesh it
> out myself, but I was/am hoping that someone interested in doing some
> elisp and web programming would/will find it fun to extend the existing
> proof-of-concept implementation.  I think it could easily grow into a
> full featured Org-mode backed wiki, or online TODO tracker, or online
> bug tracking database.

I understand and I would be happy to be part of it. I simply need to
test a bit more which way to go. I like the idea to use emacs and the
"real" exporter. Just need to think of the non-orgers...

> For speed reasons you'd probably still want the constant Emacs session
> running, and you may open up many of the same security concerns.

Yep, I was thinking about that and thought already about a emacs
daemon running. You are right, that might put me into the same
situation I have using org-ehtml directly. Would it be
possible/reasonable to create something which use e.g. apache or
lighthttpd as webbrowser and some javascript to implement the editor
functions and emacs+org-mode purely to generate the html pages? Using
a well established webserver, would give me at least the illusion that
it might be safer. There are some editors implemented in javascript
already. Maybe one could use one of them?

I think it all condense down to the phrase I gave in my early post:

org-ehtml: org-mode with editable html export and a minimal webserver
gollumn: ruby-based wiki-system which supports (partially) org-mode syntax

Both are very different concepts with a different idea behind it.

Thanks again for all the infos and support

Torsten

Re: [O] [BUG] `org-agenda-sorting-strategy' does not work in `tags-todo'

[Sebastien Vauban]

Hello,

"Sebastien Vauban" wrote:
> The following agenda view is supposed to display the tasks by ascending
> _DEADLINE timestamp_.
>
> #+begin_src emacs-lisp
>   (add-to-list 'org-agenda-custom-commands
>'("B" "Today"
>  tags-todo "DEADLINE<=\"\""
>  ((org-agenda-overriding-header "Today")
>   (org-agenda-sorting-strategy '(deadline-up t)
> #+end_src
>
> However, as you can see with the following ECM:
>
> #+begin_src org
> * Health
>   :PROPERTIES:
>   :CATEGORY: Health
>   :END:
>
> ** TODO 3Do jogging
>DEADLINE: <2013-09-09 Mon>
>
> ** TODO 2Check weekend hours at the gym
>DEADLINE: <2013-09-08 Sun>
>
> * Personal
>   :PROPERTIES:
>   :CATEGORY: Personal
>   :END:
>
> ** TODO 4Mail package to Susan
>DEADLINE: <2013-09-12 Thu>
>
> * Shopping
>   :PROPERTIES:
>   :CATEGORY: Shopping
>   :END:
>
> ** TODO 1Buy dog food
>DEADLINE: <2013-09-07 Sat>
> #+end_src
>
> it sorts the list by _category_, instead!
>
> Today (4)
>Health: TODO 3Do jogging
>Health: TODO 2Check weekend hours at the gym
>Personal:   TODO 4Mail package to Susan
>Shopping:   TODO 1Buy dog food
>
> The same sorting criteria, applied on an `agenda' view, does work.
>
> #+begin_src emacs-lisp
>   (add-to-list 'org-agenda-custom-commands
>'("G" "Agenda deadline-up"
>  agenda ""
>  ((org-agenda-span 'day)
>   (org-agenda-time-grid nil)
>   (org-agenda-sorting-strategy '(deadline-up t)
> #+end_src
> Calendar for today
> 2013-09-12 Thu 
>  5 d ago  TODO 1Buy dog food
>  4 d ago  TODO 2Check weekend hours at the gym
>  3 d ago  TODO 3Do jogging
>  Deadline TODO 4Mail package to Susan

Anybody having a hint on this?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Org-mode and continuing BBDB compatibility

[Charles Philip Chan]

"Sebastien Vauban"  writes:

Hi Sebastien:

> Weird.
>
> In the BBDB 3 version that I have from ELPA [1], I do have a file
> `bbdb-autoloads.el', but no `bbdb-loaddefs.el'...

Strange, the name was changed on 11 Dec 2011:

http://comments.gmane.org/gmane.emacs.bbdb.user/2945

Charles

-- 
Linux is obsolete
(Andrew Tanenbaum)


signature.asc
Description: PGP signature

[O] exclude certain tags from inheritance

[David Belohrad]

Dear all,

could someone help me with this?

I'm tagging my projects using different tags:

- ordinary 'whatever' tags like MARS, 2013, ProjectX ...

- tags starting with ampersand: @Me, @John, @David

- tags starting with hash #SpecificBehaviour, #LocalModification

As you can see, the first item is generic, project related, and I need
to inherit those tags within the tree. The other two items are specific:
second is to tag person who is in charge of the todo, third is a
'non-generic' tag defining very specific activity. The two I need to
have always non-inherited.

I've learned that there is org-use-tag-inheritance, which can be setup
to a regular expression. I'm not very strong in this elisp thingy. Could
someone help me to construct the expression such, that all tags starting
with @ or # will be excluded from inheritance?

many thanks

.d.

Re: [O] Org-mode and continuing BBDB compatibility

[Sebastien Vauban]

Charles Philip Chan wrote:
> "Sebastien Vauban"  writes:
>
>> You mean bbdb-autoloads?
>
> No, bbdb-loaddefs.el is part of bbdb3. Here is the instructions from the
> README file:
>
> 4) Activate BBDB:
>
>i)   If the BBDB lisp files are in a directory
> "/path/to/bbdb/lisp" you can use in your emacs init file
>
> (require 'bbdb-loaddefs "/path/to/bbdb/lisp/bbdb-loaddefs.el")
>
> This adds "/path/to/bbdb/lisp" to the load-path; so it is all
> you need to make BBDB known to your Emacs.
>
>ii)  The user variable bbdb-print-tex-path should point to the directory
> where the BBDB TeX files reside (default /usr/local/share/bbdb).

Weird.

In the BBDB 3 version that I have from ELPA [1], I do have a file
`bbdb-autoloads.el', but no `bbdb-loaddefs.el'...

Best regards,
  Seb

[1] ~/.emacs.d/elpa/bbdb-20130728.2143

-- 
Sebastien Vauban

Re: [O] Org-mode and continuing BBDB compatibility

[Charles Philip Chan]

"Sebastien Vauban"  writes:

> You mean bbdb-autoloads?

No, bbdb-loaddefs.el is part of bbdb3. Here is the instructions from the
README file:


4) Activate BBDB:

   i)   If the BBDB lisp files are in a directory
"/path/to/bbdb/lisp" you can use in your emacs init file

(require 'bbdb-loaddefs "/path/to/bbdb/lisp/bbdb-loaddefs.el")

This adds "/path/to/bbdb/lisp" to the load-path; so it is all
you need to make BBDB known to your Emacs.

   ii)  The user variable bbdb-print-tex-path should point to the directory
where the BBDB TeX files reside (default /usr/local/share/bbdb).

Charles

-- 
"World domination.  Fast"
(By Linus Torvalds)


signature.asc
Description: PGP signature

Re: [O] Org-mode and continuing BBDB compatibility

[Sebastien Vauban]

Hi Charles,

Charles Philip Chan wrote:
> Christopher Culver  writes:
>
>> I do not see anniversaries from my .bbdb file in the agenda. I know
>> that some work was done in the past with making org-mode compatible
>> with bbdb3, but are the two projects no longer compatible, or do I
>> probably have some other problem on my end?
>
> Works fine here (I am using the git version of both). How are you
> loading bbdb? You should just do a:
>
>   (require 'bbdb-loaddefs)

You mean bbdb-autoloads?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] AUCTeX key bindings within Org documents

[Fabrice Niessen]

Hello,

"Fabrice Niessen" wrote:
> Due to a friend's request, I've tried to offer AUCTeX key bindings
> within Org documents via a minor mode, called "org-auctex-keys".
> 
> If you're interested, check it out at
> https://github.com/fniessen/org-auctex-key-bindings.
> 
> Note that I'm willing to add extra AUCTeX keys -- but I don't use
> AUCTeX enough to know what's important to transfer to Org.

I've updated `org-auctex-keys' in the following way:

- `C-c C-c' runs a menu which looks a lot like AUCTeX's menu: pressing once the
  key binding calls the export process (that is, generates a PDF file);
  pressing a second time will display it (if available).

  Extra optimization: if the PDF files is newer than the Org file, then
  pressing `C-c C-c' will display it (avoiding to redo it).

- As there are a lot of conflicts between Org and AUCTeX keys, you now can call
  the standard Org command by prefixing the key binding with a `C-u' argument.
  Note that the first `C-u' is not passed onto the standard command.

  For example,

  + C-c C-c  calls my command `org-auckeys-export-dispatch'
  + C-u C-c C-c  calls the original `org-ctrl-c-ctrl-c' with no `C-u' 
arg (= 1)
  + C-u C-u C-c C-c  calls the original `org-ctrl-c-ctrl-c' with 1 `C-u' 
arg (= 4)
  + C-u C-u C-u C-c C-c  calls the original `org-ctrl-c-ctrl-c' with 2 `C-u' 
arg (= 16)
  + etc. (provided it makes sense)

- I've added a key binding to turn off/on "Org AUCKeys": `C-+'.

  So, to call a standard Org command, you can as well disable
  `org-auctex-keys', pressing the key binding you know in standard Org, and
  re-enable `org-auctex-keys', that is:

C-+ C-c C-c C-+

  to call `org-ctrl-c-ctrl-c'.

Fabrice Niessen

-- 
Fabrice Niessen
Leuven, Belgium

Re: [O] Org-mode and continuing BBDB compatibility

[Christopher Culver]

Myles English  writes:
> I think you might need:
>
> (setq org-bbdb-anniversary-field 'birthday)
>
> or 
>
> (setq org-bbdb-anniversary-field 'anniversary)
>
> depending on what you called the anniversary field.

My anniversary field in ~/.bbdb is called "anniversary". Setting this
option has no effect for me: I still do not see bbdb anniversaries in
the org-mode agenda.

Christopher Culver

Re: [O] Org-mode and continuing BBDB compatibility

[Charles Philip Chan]

Christopher Culver  writes:

Hi Christopher:

> I do not see anniversaries from my .bbdb file in the agenda. I know
> that some work was done in the past with making org-mode compatible
> with bbdb3, but are the two projects no longer compatible, or do I
> probably have some other problem on my end?

Works fine here (I am using the git version of both). How are you
loading bbdb? You should just do a:

  (require 'bbdb-loaddefs)

Charles

-- 
"Are [Linux users] lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?"
(By Matt Welsh)


signature.asc
Description: PGP signature

Re: [O] Portable formatting of export?

[Eric Schulte]

This can be done with file local variables.  See the following page of
the Emacs manual.

  (info "(emacs)Specifying File Variables")

Klaus-Dieter Bauer  writes:

> Hello!
>
> I have customized org export to both html and latex extensively since I
> disliked many of the defaults (e.g. the use of article vs scrartcl, red
> borders around pdf hyperlinks).
>
> This left me wondering however, if it is possible to create org files that
> will produce the same output on every machine, regardless of the local
> emacs customizations (of course assuming that no hacks of the export engine
> are part of the configuration).
>
> In order to make the files more portable I have been trying to make changes
> affecting export with things like #+LATEX_HEADER: but e.g. changing the
> documentclass to scrartcl seems to be possible only by changing a
> customization variable (org-latex-classes).
>
> Is it possible to make the export engine assume defaults for all
> customization variables for a file (preferably through an in-file setting)
> and to specify those customization inside the file?
>
> - Klaus

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

Re: [O] Org-mode and continuing BBDB compatibility

[Myles English]

Hi Christopher,

crcul...@christopherculver.com writes:

> I am using org-mode version 20131021 and the latest checkout of the
> bbdb3 git repository.

I am using older versions.

> Although I have the following lines in my main .org file:
>
> * Anniversaries
>:PROPERTIES:
>:CATEGORY: Anniv
>:END:
>   %%(org-bbdb-anniversaries)
>
> I do not see anniversaries from my .bbdb file in the agenda. I know that
> some work was done in the past with making org-mode compatible with
> bbdb3, but are the two projects no longer compatible, or do I probably
> have some other problem on my end?

I think you might need:

(setq org-bbdb-anniversary-field 'birthday)

or 

(setq org-bbdb-anniversary-field 'anniversary)

depending on what you called the anniversary field.

If you work out how to display birthdays and anniversaries in the same
agenda please share.

Myles

[O] Portable formatting of export?

[Klaus-Dieter Bauer]

Hello!

I have customized org export to both html and latex extensively since I
disliked many of the defaults (e.g. the use of article vs scrartcl, red
borders around pdf hyperlinks).

This left me wondering however, if it is possible to create org files that
will produce the same output on every machine, regardless of the local
emacs customizations (of course assuming that no hacks of the export engine
are part of the configuration).

In order to make the files more portable I have been trying to make changes
affecting export with things like #+LATEX_HEADER: but e.g. changing the
documentclass to scrartcl seems to be possible only by changing a
customization variable (org-latex-classes).

Is it possible to make the export engine assume defaults for all
customization variables for a file (preferably through an in-file setting)
and to specify those customization inside the file?

- Klaus

[O] Org-mode and continuing BBDB compatibility

[Christopher Culver]

I am using org-mode version 20131021 and the latest checkout of the
bbdb3 git repository. Although I have the following lines in my main
.org file:

* Anniversaries
   :PROPERTIES:
   :CATEGORY: Anniv
   :END:
  %%(org-bbdb-anniversaries)

I do not see anniversaries from my .bbdb file in the agenda. I know that
some work was done in the past with making org-mode compatible with
bbdb3, but are the two projects no longer compatible, or do I probably
have some other problem on my end?

Christopher Culver

Re: [O] Custom forwarding for a scheduled task

[Sebastien Vauban]

Hello Fletcher,

Fletcher Charest wrote:
> First of all, apologies if I'm doing something wrong - I'm not used to
> posting in mailing lists.
>
> I read in the Org manual, about scheduled tasks :
>
> "A reminder that the scheduled date has passed will be present in the
> compilation for today, until the entry is marked DONE, i.e., the task will
> automatically be forwarded until completed."
>
> Sometimes, I schedule a task but can only carry out my second day of work
> on that task one week later (or my first day if I couldn't work on it on
> the scheduled day). I would like to know if it is possible to schedule a
> task, for example, on a Sunday, and see it appear in the agenda the next
> Sunday with the mention "Sched. 2x:  TODO my task". This way I know I have
> to carry out my second day of work on that task on that day.
>
> I tried to use delays for this but couldn't obtain anything.
>
> I'm sorry if this is standard functionality or if it has been answered
> somewhere. I usually find all my answers about org-mode online but this
> time I couldn't find any info.

This hasn't been answered yet, neither is it a common request.

FWIW, I removed such scheduling info (2x, 3x...) because it scared me to hell
when it went over 99 days delay.

But, to answer you, no, I don't think it's doable in the current system.
Though, you could get more or less the same functionality by clocking time,
rescheduling your task for the available Sunday, and clock again. On that day,
you would see that you're clocking hours 8 to 15 of your work.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [PATCH] ob-ruby.el fix for :session parameter

[Eric Schulte]

Applied, Thanks!

Oleh  writes:

> Hi Eric,
>
> Here's the update.
>
> regards,
> Oleh
>
> On Mon, Oct 21, 2013 at 7:42 PM, Eric Schulte  wrote:
>> Hi Oleh,
>>
>> Thanks for submitting this patch.  Instead of the current progn/setq
>> approach could you simply add your the "conf.echo=false\n" lines to the
>> following list?
>>
>>   (list body org-babel-ruby-eoe-indicator)
>>
>> With that change I'd be happy to apply this patch.
>>
>> Also, extra thanks for submitting tests along with your patch, much
>> appreciated!
>>
>> Oleh  writes:
>>
>>> Hi all,
>>>
>>> I attach a patch to change from this behavior:
>>>
>>> #+begin_src ruby :session :results output
>>> s = "1"
>>> s = "2"
>>> s = "3"
>>> puts s
>>> #+end_src
>>>
>>> #+RESULTS:
>>> : => "1"
>>> : => "2"
>>> : => "3"
>>> : 3
>>>
>>> To this behavior
>>>
>>> #+begin_src ruby :session :results output
>>> s = "1"
>>> s = "2"
>>> s = "3"
>>> puts s
>>> #+end_src
>>>
>>> #+RESULTS:
>>> :
>>> : 3
>>>
>>> I just wrap the code in "conf.echo=false\n" and "\nconf.echo=true\n".
>>> I have to set it back to true, otherwise it hangs.
>>>
>>> regards,
>>> Oleh
>>>
>>> From e27f248f58258b78280e69cd78140e935527245e Mon Sep 17 00:00:00 2001
>>> From: Oleh Krehel 
>>> Date: Mon, 21 Oct 2013 13:03:28 +0200
>>> Subject: [PATCH] ob-ruby.el: fix result of :results output :session
>>>  combination.
>>>
>>> * lisp/ob-ruby.el (org-babel-ruby-evaluate):
>>>   set conf.echo=false for the duration of evaluation.
>>>
>>> * testing/lisp/test-ob-ruby.el (test-ob-ruby/session-output): new test.
>>> ---
>>>  lisp/ob-ruby.el  | 32 +++--
>>>  testing/lisp/test-ob-ruby.el | 49 
>>> 
>>>  2 files changed, 66 insertions(+), 15 deletions(-)
>>>  create mode 100644 testing/lisp/test-ob-ruby.el
>>>
>>> diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
>>> index af52831..ddbd0f8 100644
>>> --- a/lisp/ob-ruby.el
>>> +++ b/lisp/ob-ruby.el
>>> @@ -213,21 +213,23 @@ return the value of the last statement in BODY, as 
>>> elisp."
>>>  ;; comint session evaluation
>>>  (case result-type
>>>(output
>>> -   (mapconcat
>>> - #'identity
>>> - (butlast
>>> -  (split-string
>>> -   (mapconcat
>>> -#'org-babel-trim
>>> -(butlast
>>> - (org-babel-comint-with-output
>>> - (buffer org-babel-ruby-eoe-indicator t body)
>>> -   (mapc
>>> -(lambda (line)
>>> -  (insert (org-babel-chomp line)) (comint-send-input nil t))
>>> -(list body org-babel-ruby-eoe-indicator))
>>> -   (comint-send-input nil t)) 2)
>>> -"\n") "[\r\n]")) "\n"))
>>> +   (progn
>>> +  (setq body (concat "conf.echo=false\n" body "\nconf.echo=true\n"))
>>> +  (mapconcat
>>> +   #'identity
>>> +   (butlast
>>> +(split-string
>>> + (mapconcat
>>> +  #'org-babel-trim
>>> +  (butlast
>>> +   (org-babel-comint-with-output
>>> +   (buffer org-babel-ruby-eoe-indicator t body)
>>> + (mapc
>>> +  (lambda (line)
>>> +(insert (org-babel-chomp line)) (comint-send-input nil t))
>>> +  (list body org-babel-ruby-eoe-indicator))
>>> + (comint-send-input nil t)) 2)
>>> +  "\n") "[\r\n]")) "\n")))
>>>(value
>>> (let* ((tmp-file (org-babel-temp-file "ruby-"))
>>> (ppp (or (member "code" result-params)
>>> diff --git a/testing/lisp/test-ob-ruby.el b/testing/lisp/test-ob-ruby.el
>>> new file mode 100644
>>> index 000..74cf163
>>> --- /dev/null
>>> +++ b/testing/lisp/test-ob-ruby.el
>>> @@ -0,0 +1,49 @@
>>> +;;; test-ob-ruby.el --- tests for ob-ruby.el
>>> +
>>> +;; Copyright (c) 2013 Oleh Krehel
>>> +;; Authors: Oleh Krehel
>>> +
>>> +;; This program is free software; you can redistribute it and/or modify
>>> +;; it under the terms of the GNU General Public License as published by
>>> +;; the Free Software Foundation, either version 3 of the License, or
>>> +;; (at your option) any later version.
>>> +
>>> +;; This program is distributed in the hope that it will be useful,
>>> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> +;; GNU General Public License for more details.
>>> +
>>> +;; You should have received a copy of the GNU General Public License
>>> +;; along with this program.  If not, see .
>>> +
>>> +;;; Code:
>>> +(org-test-for-executable "ruby")
>>> +(unless (featurep 'ob-ruby)
>>> +  (signal 'missing-test-dependency "Support for Ruby code blocks"))
>>> +
>>> +(ert-deftest test-ob-ruby/session-output ()
>>> +(should (equal (org-test-with-temp-text "#+begin_src ruby :session 
>>> :results output
>>> +s = \"1\"
>>> +s = \"2\"
>>> +s = \"3\"
>>> +puts s
>>> +#+end_src"
>>> +  (org-ctrl-c-ctrl-c)
>>> +  (substring-no-properties
>>> +   (buffer-string)))
>>> +  

Re: [O] [PATCH] ob-ruby.el fix for :session parameter

[Oleh]

Hi Eric,

Here's the update.

regards,
Oleh

On Mon, Oct 21, 2013 at 7:42 PM, Eric Schulte  wrote:
> Hi Oleh,
>
> Thanks for submitting this patch.  Instead of the current progn/setq
> approach could you simply add your the "conf.echo=false\n" lines to the
> following list?
>
>   (list body org-babel-ruby-eoe-indicator)
>
> With that change I'd be happy to apply this patch.
>
> Also, extra thanks for submitting tests along with your patch, much
> appreciated!
>
> Oleh  writes:
>
>> Hi all,
>>
>> I attach a patch to change from this behavior:
>>
>> #+begin_src ruby :session :results output
>> s = "1"
>> s = "2"
>> s = "3"
>> puts s
>> #+end_src
>>
>> #+RESULTS:
>> : => "1"
>> : => "2"
>> : => "3"
>> : 3
>>
>> To this behavior
>>
>> #+begin_src ruby :session :results output
>> s = "1"
>> s = "2"
>> s = "3"
>> puts s
>> #+end_src
>>
>> #+RESULTS:
>> :
>> : 3
>>
>> I just wrap the code in "conf.echo=false\n" and "\nconf.echo=true\n".
>> I have to set it back to true, otherwise it hangs.
>>
>> regards,
>> Oleh
>>
>> From e27f248f58258b78280e69cd78140e935527245e Mon Sep 17 00:00:00 2001
>> From: Oleh Krehel 
>> Date: Mon, 21 Oct 2013 13:03:28 +0200
>> Subject: [PATCH] ob-ruby.el: fix result of :results output :session
>>  combination.
>>
>> * lisp/ob-ruby.el (org-babel-ruby-evaluate):
>>   set conf.echo=false for the duration of evaluation.
>>
>> * testing/lisp/test-ob-ruby.el (test-ob-ruby/session-output): new test.
>> ---
>>  lisp/ob-ruby.el  | 32 +++--
>>  testing/lisp/test-ob-ruby.el | 49 
>> 
>>  2 files changed, 66 insertions(+), 15 deletions(-)
>>  create mode 100644 testing/lisp/test-ob-ruby.el
>>
>> diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
>> index af52831..ddbd0f8 100644
>> --- a/lisp/ob-ruby.el
>> +++ b/lisp/ob-ruby.el
>> @@ -213,21 +213,23 @@ return the value of the last statement in BODY, as 
>> elisp."
>>  ;; comint session evaluation
>>  (case result-type
>>(output
>> -   (mapconcat
>> - #'identity
>> - (butlast
>> -  (split-string
>> -   (mapconcat
>> -#'org-babel-trim
>> -(butlast
>> - (org-babel-comint-with-output
>> - (buffer org-babel-ruby-eoe-indicator t body)
>> -   (mapc
>> -(lambda (line)
>> -  (insert (org-babel-chomp line)) (comint-send-input nil t))
>> -(list body org-babel-ruby-eoe-indicator))
>> -   (comint-send-input nil t)) 2)
>> -"\n") "[\r\n]")) "\n"))
>> +   (progn
>> +  (setq body (concat "conf.echo=false\n" body "\nconf.echo=true\n"))
>> +  (mapconcat
>> +   #'identity
>> +   (butlast
>> +(split-string
>> + (mapconcat
>> +  #'org-babel-trim
>> +  (butlast
>> +   (org-babel-comint-with-output
>> +   (buffer org-babel-ruby-eoe-indicator t body)
>> + (mapc
>> +  (lambda (line)
>> +(insert (org-babel-chomp line)) (comint-send-input nil t))
>> +  (list body org-babel-ruby-eoe-indicator))
>> + (comint-send-input nil t)) 2)
>> +  "\n") "[\r\n]")) "\n")))
>>(value
>> (let* ((tmp-file (org-babel-temp-file "ruby-"))
>> (ppp (or (member "code" result-params)
>> diff --git a/testing/lisp/test-ob-ruby.el b/testing/lisp/test-ob-ruby.el
>> new file mode 100644
>> index 000..74cf163
>> --- /dev/null
>> +++ b/testing/lisp/test-ob-ruby.el
>> @@ -0,0 +1,49 @@
>> +;;; test-ob-ruby.el --- tests for ob-ruby.el
>> +
>> +;; Copyright (c) 2013 Oleh Krehel
>> +;; Authors: Oleh Krehel
>> +
>> +;; This program is free software; you can redistribute it and/or modify
>> +;; it under the terms of the GNU General Public License as published by
>> +;; the Free Software Foundation, either version 3 of the License, or
>> +;; (at your option) any later version.
>> +
>> +;; This program is distributed in the hope that it will be useful,
>> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +;; GNU General Public License for more details.
>> +
>> +;; You should have received a copy of the GNU General Public License
>> +;; along with this program.  If not, see .
>> +
>> +;;; Code:
>> +(org-test-for-executable "ruby")
>> +(unless (featurep 'ob-ruby)
>> +  (signal 'missing-test-dependency "Support for Ruby code blocks"))
>> +
>> +(ert-deftest test-ob-ruby/session-output ()
>> +(should (equal (org-test-with-temp-text "#+begin_src ruby :session 
>> :results output
>> +s = \"1\"
>> +s = \"2\"
>> +s = \"3\"
>> +puts s
>> +#+end_src"
>> +  (org-ctrl-c-ctrl-c)
>> +  (substring-no-properties
>> +   (buffer-string)))
>> +"#+begin_src ruby :session :results output
>> +s = \"1\"
>> +s = \"2\"
>> +s = \"3\"
>> +puts s
>> +#+end_src
>> +
>> +#+RESULTS:
>> +:
>> +: 3
>> +
>> +")))
>> +
>> +(provide 'test-ob-

Re: [O] [PATCH] ob-ruby.el fix for :session parameter

[Eric Schulte]

Hi Oleh,

Thanks for submitting this patch.  Instead of the current progn/setq
approach could you simply add your the "conf.echo=false\n" lines to the
following list?

  (list body org-babel-ruby-eoe-indicator)

With that change I'd be happy to apply this patch.

Also, extra thanks for submitting tests along with your patch, much
appreciated!

Oleh  writes:

> Hi all,
>
> I attach a patch to change from this behavior:
>
> #+begin_src ruby :session :results output
> s = "1"
> s = "2"
> s = "3"
> puts s
> #+end_src
>
> #+RESULTS:
> : => "1"
> : => "2"
> : => "3"
> : 3
>
> To this behavior
>
> #+begin_src ruby :session :results output
> s = "1"
> s = "2"
> s = "3"
> puts s
> #+end_src
>
> #+RESULTS:
> :
> : 3
>
> I just wrap the code in "conf.echo=false\n" and "\nconf.echo=true\n".
> I have to set it back to true, otherwise it hangs.
>
> regards,
> Oleh
>
> From e27f248f58258b78280e69cd78140e935527245e Mon Sep 17 00:00:00 2001
> From: Oleh Krehel 
> Date: Mon, 21 Oct 2013 13:03:28 +0200
> Subject: [PATCH] ob-ruby.el: fix result of :results output :session
>  combination.
>
> * lisp/ob-ruby.el (org-babel-ruby-evaluate):
>   set conf.echo=false for the duration of evaluation.
>
> * testing/lisp/test-ob-ruby.el (test-ob-ruby/session-output): new test.
> ---
>  lisp/ob-ruby.el  | 32 +++--
>  testing/lisp/test-ob-ruby.el | 49 
> 
>  2 files changed, 66 insertions(+), 15 deletions(-)
>  create mode 100644 testing/lisp/test-ob-ruby.el
>
> diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
> index af52831..ddbd0f8 100644
> --- a/lisp/ob-ruby.el
> +++ b/lisp/ob-ruby.el
> @@ -213,21 +213,23 @@ return the value of the last statement in BODY, as 
> elisp."
>  ;; comint session evaluation
>  (case result-type
>(output
> -   (mapconcat
> - #'identity
> - (butlast
> -  (split-string
> -   (mapconcat
> -#'org-babel-trim
> -(butlast
> - (org-babel-comint-with-output
> - (buffer org-babel-ruby-eoe-indicator t body)
> -   (mapc
> -(lambda (line)
> -  (insert (org-babel-chomp line)) (comint-send-input nil t))
> -(list body org-babel-ruby-eoe-indicator))
> -   (comint-send-input nil t)) 2)
> -"\n") "[\r\n]")) "\n"))
> +   (progn
> +  (setq body (concat "conf.echo=false\n" body "\nconf.echo=true\n"))
> +  (mapconcat
> +   #'identity
> +   (butlast
> +(split-string
> + (mapconcat
> +  #'org-babel-trim
> +  (butlast
> +   (org-babel-comint-with-output
> +   (buffer org-babel-ruby-eoe-indicator t body)
> + (mapc
> +  (lambda (line)
> +(insert (org-babel-chomp line)) (comint-send-input nil t))
> +  (list body org-babel-ruby-eoe-indicator))
> + (comint-send-input nil t)) 2)
> +  "\n") "[\r\n]")) "\n")))
>(value
> (let* ((tmp-file (org-babel-temp-file "ruby-"))
> (ppp (or (member "code" result-params)
> diff --git a/testing/lisp/test-ob-ruby.el b/testing/lisp/test-ob-ruby.el
> new file mode 100644
> index 000..74cf163
> --- /dev/null
> +++ b/testing/lisp/test-ob-ruby.el
> @@ -0,0 +1,49 @@
> +;;; test-ob-ruby.el --- tests for ob-ruby.el
> +
> +;; Copyright (c) 2013 Oleh Krehel
> +;; Authors: Oleh Krehel
> +
> +;; This program is free software; you can redistribute it and/or modify
> +;; it under the terms of the GNU General Public License as published by
> +;; the Free Software Foundation, either version 3 of the License, or
> +;; (at your option) any later version.
> +
> +;; This program is distributed in the hope that it will be useful,
> +;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +;; GNU General Public License for more details.
> +
> +;; You should have received a copy of the GNU General Public License
> +;; along with this program.  If not, see .
> +
> +;;; Code:
> +(org-test-for-executable "ruby")
> +(unless (featurep 'ob-ruby)
> +  (signal 'missing-test-dependency "Support for Ruby code blocks"))
> +
> +(ert-deftest test-ob-ruby/session-output ()
> +(should (equal (org-test-with-temp-text "#+begin_src ruby :session 
> :results output
> +s = \"1\"
> +s = \"2\"
> +s = \"3\"
> +puts s
> +#+end_src"
> +  (org-ctrl-c-ctrl-c)
> +  (substring-no-properties
> +   (buffer-string)))
> +"#+begin_src ruby :session :results output
> +s = \"1\"
> +s = \"2\"
> +s = \"3\"
> +puts s
> +#+end_src
> +
> +#+RESULTS:
> +: 
> +: 3
> +
> +")))
> +
> +(provide 'test-ob-ruby)
> +
> +;;; test-ob-ruby.el ends here

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

Re: [O] Create sub-directories and files from within org

[Skip Collins]

On Sun, Oct 20, 2013 at 12:58 PM, John Kitchin  wrote:
>
> I don't understand what you are trying to do here. you could write a lisp
> function that you run in the ** project name heading that creates a directory
> by that name. But what would the txt files in that directory be?

I requested something like this functionality some time ago but never
found an answer. I create new projects in projects.org, via capture or
direct editing. Each project is a top-level heading that may sometimes
contain sub-headings, todos, etc. Most often it remains a simple
top-level heading containing a drawer but no body or subheadings. It
takes one of the following states: PROJ, DONE, CANCELED, or DORMANT. I
have several agenda views that track active projects (i.e. not done,
not canceled, and not dormant), and other tag attributes (personal,
professional, ...). I use a set of optional tags to track where
project data is kept: :org:, :computer:, :email:, :file:, :binder:,
etc. Many projects have the :computer: tag and a corresponding folder
on my hard drive with various file types stored there including txt,
docx, org, pdf, jpeg, etc. I would very much like a way to quickly
create that folder with the unique project name that I assign in the
top-level heading. It would be super nice if this automagic folder
creation feature also creates a link to the folder inside my
projects.org file.

Re: [O] [RFC] Do not declare drawers to use them

[Achim Gratz]

Nicolas Goaziou writes:
> At the moment, in order to use a drawer, one has to declare its name
> through `org-drawers' variable or DRAWERS keyword first.
>
> I'd like to simplify a bit the process and let the user create drawers
> on the fly instead. A valid name includes any word constituent, hyphen
> and underscore characters. Case isn't significant.

That would be very welcome.

> It also cleans the internals (i.e. some dynamically scoped variables are
> removed) and makes syntax more portable. But we lose completion for
> drawer names.

I suggest that completion should still look at configured drawer names.


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

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

Re: [O] org-mode based groupware wiki

[Eric Schulte]

Torsten Wagner  writes:

> Dear Wally,
> Dear Eric,
>
> thanks for the replies and sorry for the long delay. Interesting that
> there is an update on org-ruby just in the middle of my decision
> pathway ;).
> Until know I thought org-ruby is pretty much orphaned and that by time
> it will start to fail on the growing changes done in org-mode.
>
> On the other hand with all the help on the list I got org-ehtml
> working now. It was indeed a missing requirement call (require 'assoc)
> did the job.
> Now I was able to test both gollumn and org-ehtml it puts me into a dilemma.
>

Multiple viable options for Org-mode wikis is a great problem to have.

>
> From user (esp. non-org-user) perspective gollumn seems much more
> attractive. The editor is more user friendly for non-orgers and the
> integrated git versioning is working pretty stable.

See the "Integrating with version control" section of the org-ehtml
README [1].  It provides VC integration with just a couple of lines of
Emacs Lisp which could be added to the webserver's Emacs config.

> Gollumn itself seems to run on the shoulder of giants and keep itself
> rather small.

Org-ehtml is itself just a tiny hack which (I think) neatly combines the
power of the new Org export system, and the power of Elnode running on
top of a full fledged Emacs instance.  Org-ehtml is more than two orders
of magnitude smaller than gollum (judging by compressed source code).

$ find gollum/lib -type f -exec cat {} \+|bzip2|wc -c 
749992

$ find org-ehtml/src -type f -exec cat {} \+|bzip2|wc -c
6042

> Overall, a quite positive impression. However, it depends on the
> org-ruby package, which still understand only a subset of org-modes
> features. It seems to me somehow a hunting task to keep track with the
> fast pace of the org-mode development. This does not only include new
> features but also slight differences between the original org-mode
> export and the org-ruby parsing. It might be as simple as an extra
> blank here or there, which can be quite troublesome form time to time.
>
> e-html works great too. It is somehow a little bit more a web-based
> editable org-mode, whereas gollumn is a wiki-system which supports
> org-mode. org-html would do a perfect job for myself if I am the only
> user for this wiki. However, I frighten that non-orgers have a harder
> time to use it compare to gollumn. For some reason which I can't
> explain, I feel a bit nervous about running  an emacs session
> continuously on my server to provide a website. Not sure where the
> fear comes from. Maybe it is just because of my bad elisp skills ;)
> Overall, it works now and it does a good job but I can't avoid the
> feeling that all of it might be a bit fragile (as it might brake on
> arbitrarily changes on elnode, emacs, org-mode). However, it has the
> great benefit to be 100% up-to-date with whatever org-mode supports
> now or in the future and the output of a static page would be the same
> as the dynamic page. I even could create PDF versions if needed e.g.
> for static archiving.
>

Understood.  I hope I haven't wasted your time and I appreciated that
you got org-ehtml running.  Gollum is a very mature option, and is
probably your best bet unless you fall into one of the following.

1. need more esoteric features of Org-mode or
2. you like the idea of being able to run arbitrary Emacs Lisp as part
   of the editing process or
3. (like me) you don't have ruby installed on your system and a ruby web
   server seems like a lot of bloat for a wiki

The reason Gollum is so much larger is because it has a large team of
people adding the many handlers for edge cases and extra bells and
whistles which make for a robust tool.

My goal with org-ehtml was to produce a tiny working and (most
importantly) easily hackable core.  I don't have time to really flesh it
out myself, but I was/am hoping that someone interested in doing some
elisp and web programming would/will find it fun to extend the existing
proof-of-concept implementation.  I think it could easily grow into a
full featured Org-mode backed wiki, or online TODO tracker, or online
bug tracking database.

>
> I do not exactly now the intentions for org-ruby. Maybe Wally like to
> elaborate on this. Maybe org-ruby can catch up faster with the new
> exporter features of org-mode now that org-mode gets a more
> standardized syntax.
>
> At the moment, for me the best would be to combine both worlds
> somehow. I notice that gollum allows to define/call new parsers. Would
> it be possible to call emacs and start and html export on changes
> saved in the webbrowser? In other words why not calling emacs directly
> to do the html export? I would assume that the code which has to be
> added to gollum would be minimal and the same would be true for the
> few lines of lisp code to create the html page.
>

This would probably not be difficult.  You'd probably want to start an
EmacsClient instance when the web server boots, and then intera

[O] Custom forwarding for a scheduled task

[Fletcher Charest]

Dear community,

First of all, apologies if I'm doing something wrong - I'm not used to
posting in mailing lists.

I read in the Org manual, about scheduled tasks :

"A reminder that the scheduled date has passed will be present in the
compilation for today, until the entry is marked DONE, i.e., the task will
automatically be forwarded until completed."

Sometimes, I schedule a task but can only carry out my second day of work
on that task one week later (or my first day if I couldn't work on it on
the scheduled day). I would like to know if it is possible to schedule a
task, for example, on a Sunday, and see it appear in the agenda the next
Sunday with the mention "Sched. 2x:  TODO my task". This way I know I have
to carry out my second day of work on that task on that day.

I tried to use delays for this but couldn't obtain anything.

I'm sorry if this is standard functionality or if it has been answered
somewhere. I usually find all my answers about org-mode online but this
time I couldn't find any info.

Best regards,

Anthony

Re: [O] [RFC] Change some defcustoms into defcont

[Nicolas Goaziou]

Carsten Dominik  writes:

> The documentation of defconst says:
>
>> Define SYMBOL as a constant variable.
>> This declares that neither programs nor users should ever change the
>> value.  This constancy is not actually enforced by Emacs Lisp, but
>> SYMBOL is marked as a special variable so that it is never lexically
>> bound.
>
> So it is pretty clear about the intent of such a definition, which is
> to never change it - even though it does not enforce it.

I must have been clear as mud, because that's exactly what I'm
suggesting since the beginning of this thread: set "DEADLINE" and al. in
stone, and never change them again.

I have been pointing out, though, that it would not break previous
changes if they were done with `setq', according to how defconst are
handled. But I never intended to make it a feature, nor did I suggest
that was desirable.

> As you have said, we still want to allow users in principle to change
> these variables.

No, I haven't said such a thing. I said, verbatim, "In principle, they
mustn't be changed", which means quite the contrary.

> They have been defcustoms in the past, some people will have changed
> them. Their setup will break when they switch to a new version.

Indeed. But that's easy to fix programmatically.

> That is why I object to changing their status. I think it causes
> unnecessary breakage, and we can prevent this by keeping them
> defcustom. Nothing is really gained by changing their status.

It fixes at least a bug, prevents headaches by simplifying maintenance,
makes Org syntax more portable and more cache friendly. I wouldn't call
that "nothing".

Anyway, I have well understood that you don't want to change their
status. So be it.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-mode based groupware wiki

[Torsten Wagner]

Dear Wally,
Dear Eric,

thanks for the replies and sorry for the long delay. Interesting that
there is an update on org-ruby just in the middle of my decision
pathway ;).
Until know I thought org-ruby is pretty much orphaned and that by time
it will start to fail on the growing changes done in org-mode.

On the other hand with all the help on the list I got org-ehtml
working now. It was indeed a missing requirement call (require 'assoc)
did the job.
Now I was able to test both gollumn and org-ehtml it puts me into a dilemma.

>From user (esp. non-org-user) perspective gollumn seems much more
attractive. The editor is more user friendly for non-orgers and the
integrated git versioning is working pretty stable. Gollumn itself
seems to run on the shoulder of giants and keep itself rather small.
Overall, a quite positive impression. However, it depends on the
org-ruby package, which still understand only a subset of org-modes
features. It seems to me somehow a hunting task to keep track with the
fast pace of the org-mode development. This does not only include new
features but also slight differences between the original org-mode
export and the org-ruby parsing. It might be as simple as an extra
blank here or there, which can be quite troublesome form time to time.

e-html works great too. It is somehow a little bit more a web-based
editable org-mode, whereas gollumn is a wiki-system which supports
org-mode. org-html would do a perfect job for myself if I am the only
user for this wiki. However, I frighten that non-orgers have a harder
time to use it compare to gollumn. For some reason which I can't
explain, I feel a bit nervous about running  an emacs session
continuously on my server to provide a website. Not sure where the
fear comes from. Maybe it is just because of my bad elisp skills ;)
Overall, it works now and it does a good job but I can't avoid the
feeling that all of it might be a bit fragile (as it might brake on
arbitrarily changes on elnode, emacs, org-mode). However, it has the
great benefit to be 100% up-to-date with whatever org-mode supports
now or in the future and the output of a static page would be the same
as the dynamic page. I even could create PDF versions if needed e.g.
for static archiving.

I do not exactly now the intentions for org-ruby. Maybe Wally like to
elaborate on this. Maybe org-ruby can catch up faster with the new
exporter features of org-mode now that org-mode gets a more
standardized syntax.

At the moment, for me the best would be to combine both worlds
somehow. I notice that gollum allows to define/call new parsers. Would
it be possible to call emacs and start and html export on changes
saved in the webbrowser? In other words why not calling emacs directly
to do the html export? I would assume that the code which has to be
added to gollum would be minimal and the same would be true for the
few lines of lisp code to create the html page.

That would allow me to use the non-orger friendly gollumn and get the
same accurate result as I do with org-ehtml. However, it would only
call emacs from time to time instead of a constant emacs session
running.

Maybe this (sorry) very long mail helps me to get the best of both worlds ;)

Thanks for help and support

Torsten






On 16 October 2013 19:52, Waldemar Quevedo  wrote:
> Hello Torsten,
>
>> - Enhance org-ruby?
> I would be glad to help out in this regard. About the completeness of the
> implementation of the Org mode ruby parser, it would be very helpful for me
> to have a set of examples that describe how each one of the features of Org
> mode Emacs exporter should be rendered in to HTML.
>
> I tried to do some work about this some time ago to identify the coverage of
> Org ruby HTML exporting compared to the Org mode Emacs exporter:
> https://github.com/wallyqs/org-mode-features/blob/master/features.org
> https://github.com/bdewey/org-ruby/tree/master/spec/html_examples/
> Is there a set of examples of all the features from Org mode anywhere?
>
> By the way, recently Github has upgraded to the 0.8.1 version of the
> org-ruby gem, so Org mode rendering to HTML should have improved a lot
> (previous version they used was 0.5.3 so it took a while for them to
> evaluate upgrading the gem).
> https://github.com/github/markup/issues/186#issuecomment-25342870
>
> Until I have identified the coverage, my current approach with developing
> Org ruby is 'on demand', so if you find and issue please submit to the
> issues tracker on Github: https://github.com/bdewey/org-ruby/issues
>
> Cheers,
>
> - Wally
>
>
>
>
> On Fri, Oct 4, 2013 at 8:57 PM, Torsten Wagner 
> wrote:
>>
>> Hi,
>> recently I discovered gollumn [1] and was amazed to see that there is a
>> software which allows non-orgers to work with / read my org-files and which
>> even use git as the backend to get all save and nice together, even if
>> working concurrently on the same files.
>>
>> I was wondering, because I never read about gollum in this ML and my
>> search o

Re: [O] [RFC] Change some defcustoms into defcont

[Carsten Dominik]

Hi Nicolas,

On 21.10.2013, at 12:51, Nicolas Goaziou  wrote:

> Carsten Dominik  writes:
> 
>> On 21.10.2013, at 10:56, Nicolas Goaziou  wrote:
> 
>>> That's exactly the point of the defconst: you can still modify the
>>> variable, but it sends a strong message to the user. Also, it's not
>>> about deprecation: code base should still rely on these variables.
>> 
>> This is where I disagree.  I think the Emacs implementation of defconst
>> is broken, and retained in this way only for backward compatibility.
> 
> I won't judge Elisp implementation. AFAIC, defining a variable as
> a defconst means : "change it at your own risk", which is exactly my
> point.

The documentation of defconst says:

> Define SYMBOL as a constant variable.
> This declares that neither programs nor users should ever change the
> value.  This constancy is not actually enforced by Emacs Lisp, but
> SYMBOL is marked as a special variable so that it is never lexically
> bound.

So it is pretty clear about the intent of such a definition, which is
to never change it - even though it does not enforce it.

As you have said, we still want to allow users in principle to change
these variables.  They have been defcustoms in the past, some people will
have changed them.  Their setup will break when they switch to a new
version.  That is why I object to changing their status.  I think it
causes unnecessary breakage, and we can prevent this by keeping them
defcustom.  Nothing is really gained by changing their status.

- Carsten



> 
> Anyway, FWIW, even a defvar would suffice.
> 
>> If we still allow users to edit this in principle,
> 
> We have no way to prevent them from modifying it. In principle, they
> mustn't be changed, but it's Free software.
> 
>> I do not think we should make these variables defconst. If editing is
>> not even depreciated, there is even less reason to make this change.
>> How about we add a sentence like this:
>> 
>> Changing this variable may cause compatibility problems with other users
>> trying to edit your file in Emacs.
> 
> It's not only about compatibility problems. As I pointed out, modifying
> these variable can break your own Org.
> 
> Using a defcustom is ambiguous here. On the one hand, we say "You can
> modify this variable, we even help you to do so" and on the other hand
> "Upon changing this variable, horrible things can happen".
> 
> Let's, at least, not help users shoot themselves in the foot.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

[O] [PATCH] ob-ruby.el fix for :session parameter

[Oleh]

Hi all,

I attach a patch to change from this behavior:

#+begin_src ruby :session :results output
s = "1"
s = "2"
s = "3"
puts s
#+end_src

#+RESULTS:
: => "1"
: => "2"
: => "3"
: 3

To this behavior

#+begin_src ruby :session :results output
s = "1"
s = "2"
s = "3"
puts s
#+end_src

#+RESULTS:
:
: 3

I just wrap the code in "conf.echo=false\n" and "\nconf.echo=true\n".
I have to set it back to true, otherwise it hangs.

regards,
Oleh


0001-ob-ruby.el-fix-result-of-results-output-session-comb.patch
Description: Binary data

[O] Bug: verbatim export of python code block with numpy array returns wrong value [8.2.1 (8.2.1-10-g9c1ef6-elpaplus @ /Users/sbagley/Dropbox/emacsd/elpa/org-plus-contrib-20131014/)]

[Steven Bagley]

The following file contents, when exported (to HTML or pdf), produce
incorrect output:
#+PROPERTY: header-args:python :session "*Python*"
#+PROPERTY: exports both
#+PROPERTY: results value verbatim
#+BEGIN_SRC python
import numpy as np
np.array([1, 2, 3])
#+END_SRC

The resulting value block contains [1 2 3], which is not the print
representation of that numpy array. I suspect the problem arises in
ob-python.el from the use of str() instead of repr(). Thanks.
--Steve

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

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

Your bug report will be posted to the Org-mode mailing list.




Emacs  : GNU Emacs 24.3.1 (x86_64-apple-darwin11.4.2, Carbon Version
1.6.0 AppKit 1138.51)
 of 2013-09-24 on Yukikaze.local
Package: Org-mode version 8.2.1 (8.2.1-10-g9c1ef6-elpaplus @
/Users/sbagley/Dropbox/emacsd/elpa/org-plus-contrib-20131014/)

Re: [O] Beamer export: How to handle overlayarea

[James Harkins]

On Oct 21, 2013 6:12 PM, "Nicolas Goaziou"  wrote:
> Optional arguments are in square brackets in LaTeX. Try %r instead, so
> you can write:
>
>   *** {0.9\textwidth}{0.7\textheight}   :B_overlayarea:
>   :PROPERTIES:
>   :BEAMER_env: overlayarea
>   :END:

Ah, OK, that's better.

It's not easy to grasp the correct terminology and structure from the
available documentation. I do appreciate the excellent help from the list
in such cases!

This part of the documentation might benefit from some examples of
generating different types of beamer syntax -- when to use properties, when
to use headline text, etc. I wouldn't have guessed to use the headline text
because I was thinking of parameters or arguments.

> > Also, side note, [1] seems not to document BEAMER_OPT for environments
> > within a frame. Reading this page, you would think you could only use
> > it for frames. I had to dig into the source code to find how to
> > populate %o.
>
> Would you mind suggesting a better phrasing?

Under "Block environments and overlay specifications," where it discusses
custom environments, I would add:

~~
- Environment options may be given using the BEAMER_opt property. They will
be enclosed in square brackets and inserted where %o appears in the
environment definition.
(with an example, but I can't think of one now)

- Additional arguments may be written into the environment's headline, and
inserted into the LaTeX string using %r (raw headline text, no processing).
~~

I think it's important to mention it in the section where it can be used.
My faulty conclusion was based on the fact that the only mention of _opt is
in a section about frames.

hjh
hjh

Re: [O] [RFC] Change some defcustoms into defcont

[Nicolas Goaziou]

Carsten Dominik  writes:

> On 21.10.2013, at 10:56, Nicolas Goaziou  wrote:

>> That's exactly the point of the defconst: you can still modify the
>> variable, but it sends a strong message to the user. Also, it's not
>> about deprecation: code base should still rely on these variables.
>
> This is where I disagree.  I think the Emacs implementation of defconst
> is broken, and retained in this way only for backward compatibility.

I won't judge Elisp implementation. AFAIC, defining a variable as
a defconst means : "change it at your own risk", which is exactly my
point.

Anyway, FWIW, even a defvar would suffice.

> If we still allow users to edit this in principle,

We have no way to prevent them from modifying it. In principle, they
mustn't be changed, but it's Free software.

> I do not think we should make these variables defconst. If editing is
> not even depreciated, there is even less reason to make this change.
> How about we add a sentence like this:
>
> Changing this variable may cause compatibility problems with other users
> trying to edit your file in Emacs.

It's not only about compatibility problems. As I pointed out, modifying
these variable can break your own Org.

Using a defcustom is ambiguous here. On the one hand, we say "You can
modify this variable, we even help you to do so" and on the other hand
"Upon changing this variable, horrible things can happen".

Let's, at least, not help users shoot themselves in the foot.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Change some defcustoms into defcont

[Carsten Dominik]

On 21.10.2013, at 10:56, Nicolas Goaziou  wrote:

> Hello,
> 
> Carsten Dominik  writes:
> 
>> I think this change breaks user setups.  I don't know how many
>> people do change these keywords, but I know some do, if
>> only for localization purposes.  I myself have modified the
>> archive keyword in some cases, if I use this feature for a
>> different purpose.
> 
> I don't think it breaks their setup, since you can do:
> 
>  (setq org-deadline-string "SOMETHING:")

Yes.  But in particular the less well versed users will likely
have used customize.

> 
> Of course, if they change it with `custom-set-variables', they will have
> to change it.
> 
>> You probably want to do this to make Org syntax less fragile.  
> 
> Correct.
> 
>> However, I think it can also be achieved by leaving these as defcustom
>> and discouraging changes in the docstring with a standard sentence
>> about about deprecation.
> 
> That's exactly the point of the defconst: you can still modify the
> variable, but it sends a strong message to the user. Also, it's not
> about deprecation: code base should still rely on these variables.

This is where I disagree.  I think the Emacs implementation of defconst
is broken, and retained in this way only for backward compatibility.
If we still allow users to edit this in principle, I do not think we
should make these variables defconst.  If editing is not
even depreciated, there is even less reason to make this change.
How about we add a sentence like this:

Changing this variable may cause compatibility problems with other users
trying to edit your file in Emacs.

> 
>> Your most important argument to me seems about efficiency of cashing.
>> We can fix this by providing :set methods for the customize entries
>> that will trigger global cache erasing, so that you do not need to
>> programmatically check this all the time.
> 
> I know, and I still have to do it for variables like
> `org-todo-keywords', which are meant to be modified.
> 
> My main concern is about core Org syntax.

- Carsten

Re: [O] [RFC] Do not declare drawers to use them

[Carsten Dominik]

On 21.10.2013, at 12:03, Nicolas Goaziou  wrote:

> Hello,
> 
> Carsten Dominik  writes:
> 
>> I think one objection agains this patch is that, I think, MobileOrg
>> relies on #+DRAWERS lines to be present to define drawers.
> 
> The patch also contains org-mobile.el modifications.
> 
>> Maybe the MobileOrg maintainers for both Android and iOS can chime in
>> here?
> 
> Obviously, a double check cannot hurt.
> 
>> Otherwise I don't have a significant objection against this change.
>> I am wondering if it is going to introduce spurious drawers and
>> parsing errors if someone happens to have a string :xxx: on a line by
>> itself in the buffer. This might be unlikely, but I am not really
>> sure.
> 
> Actually, as far as the parser goes, :xxx: is insufficient to define
> a drawer. Indeed, the drawer has to be complete, i.e. it has to contain
> the :END: part.
> 
> An incomplete drawer does not trigger a parsing error: it is parsed as
> a mere paragraph.

OK, sounds good to me, then.

- Carsten

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

Re: [O] Beamer export: How to handle overlayarea

[Nicolas Goaziou]

Hello,

James Harkins  writes:

> Per the beamer user guide, the syntax of the overlayarea environment is:
>
> \begin{overlayarea}{area width}{area height}
>   environment contents
> \end{overlayarea}
>
> I can't figure out how to get the width and height in properly.
>
> From the customize interface, I added overlayarea as follows:
>
> '(org-beamer-environments-extra (quote (("CJK" "Z" "\\begin{CJK}%a%H"
> "\\end{CJK}") ("onlyenv" "O" "\\begin{onlyenv}%a" "\\end{onlyenv}")
> ("overlayarea" "Y" "\\begin{overlayarea}%o%a" "\\end{overlayarea}"
>
> And I can plug text into %o using the BEAMER_OPT property:
>
> *** Overlays:B_overlayarea:
>:PROPERTIES:
>:BEAMER_env: overlayarea
>:BEAMER_OPT: {0.9\textwidth}{0.7\textheight}
>:END:
>
> -->
>
> \begin{overlayarea}[{0.9\textwidth}{0.7\textheight}]
>
> Oh, hello, BEAMER_OPT automatically adds square brackets, how
> charming.

Optional arguments are in square brackets in LaTeX. Try %r instead, so
you can write:

  *** {0.9\textwidth}{0.7\textheight}   :B_overlayarea:
  :PROPERTIES:
  :BEAMER_env: overlayarea
  :END:

> Still, I wonder if there shouldn't be, e.g., %O for
> options-without-brackets. Because that was 45 minutes I spent NOT
> writing my slides :-|

Options without brackets are not options anymore, but random arguments.

> Also, side note, [1] seems not to document BEAMER_OPT for environments
> within a frame. Reading this page, you would think you could only use
> it for frames. I had to dig into the source code to find how to
> populate %o.

Would you mind suggesting a better phrasing?


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Do not declare drawers to use them

[Nicolas Goaziou]

Hello,

Carsten Dominik  writes:

> I think one objection agains this patch is that, I think, MobileOrg
> relies on #+DRAWERS lines to be present to define drawers.

The patch also contains org-mobile.el modifications.

> Maybe the MobileOrg maintainers for both Android and iOS can chime in
> here?

Obviously, a double check cannot hurt.

> Otherwise I don't have a significant objection against this change.
> I am wondering if it is going to introduce spurious drawers and
> parsing errors if someone happens to have a string :xxx: on a line by
> itself in the buffer. This might be unlikely, but I am not really
> sure.

Actually, as far as the parser goes, :xxx: is insufficient to define
a drawer. Indeed, the drawer has to be complete, i.e. it has to contain
the :END: part.

An incomplete drawer does not trigger a parsing error: it is parsed as
a mere paragraph.


Regards,

-- 
Nicolas Goaziou

Re: [O] Beamer export: How to handle overlayarea

[Suvayu Ali]

On Mon, Oct 21, 2013 at 03:52:14PM +0800, James Harkins wrote:
> 
> Also, side note, [1] seems not to document BEAMER_OPT for environments
> within a frame. Reading this page, you would think you could only use it for
> frames. I had to dig into the source code to find how to populate %o.
> 
> hjh
> 
> [1] http://orgmode.org/worg/exporters/beamer/ox-beamer.html
> 

This page has not been updated in a long time.  It was written before
there was a section on the new beamer exporter in the manual.  I don't
have the time at the moment, I won't have time in the coming months
either.  So if you have ideas about how to improve the article, please
feel free to add.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] [RFC] Change some defcustoms into defcont

[Nicolas Goaziou]

Hello,

Carsten Dominik  writes:

> I think this change breaks user setups.  I don't know how many
> people do change these keywords, but I know some do, if
> only for localization purposes.  I myself have modified the
> archive keyword in some cases, if I use this feature for a
> different purpose.

I don't think it breaks their setup, since you can do:

  (setq org-deadline-string "SOMETHING:")

Of course, if they change it with `custom-set-variables', they will have
to change it.

> You probably want to do this to make Org syntax less fragile.  

Correct.

> However, I think it can also be achieved by leaving these as defcustom
> and discouraging changes in the docstring with a standard sentence
> about about deprecation.

That's exactly the point of the defconst: you can still modify the
variable, but it sends a strong message to the user. Also, it's not
about deprecation: code base should still rely on these variables.

> Your most important argument to me seems about efficiency of cashing.
> We can fix this by providing :set methods for the customize entries
> that will trigger global cache erasing, so that you do not need to
> programmatically check this all the time.

I know, and I still have to do it for variables like
`org-todo-keywords', which are meant to be modified.

My main concern is about core Org syntax.


Regards,

-- 
Nicolas Goaziou

Re: [O] Beamer export: How to handle overlayarea

[Sebastien Vauban]

Hello James,

James Harkins wrote:
> Per the beamer user guide, the syntax of the overlayarea environment is:
>
> \begin{overlayarea}{area width}{area height}
>   environment contents
> \end{overlayarea}
>
> I can't figure out how to get the width and height in properly.

Have a look at
http://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00922.html.

You see you could use ":options". HTH.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Change some defcustoms into defcont

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> I'd like to suggest changing the following defcustom variables into
> defconst:
>
>   - org-deadline-string
>   - org-scheduled-string
>   - org-closed-string
>   - org-clock-string
>   - org-comment-string
>   - org-quote-string
>   - org-effort-property
>   - org-archive-tag

At first, I thought: "I certainly have changed at least one of them" (such
`org-log-note-headings' for which I changed the `state' string to "State %-12S
-> %-12s %t" -- as I prefer the FROM -> TO presentation of state changes).

Though, FWIW, no, these are still the original values in my case as well.

> There's no fundamental reason to change these, as they belong to Org
> syntax, much like star character for headlines and ":END:" closing
> string for drawers.
>
> They can also introduce bugs in code when modified (e.g. modifying
> `org-effort-property' breaks `ox-taskjuggler'). Of course, this can be
> avoided with careful checks, but this puts an extra burden on developers
> for a tiny benefit for the user.
>
> Eventually, they can be costly, since changing any of them implies that
> cache in every Org buffer must be erased.
>
> Allowing customization is generally good, but I think Org syntax should
> never be a moving target.
>
> Note that this shouldn't introduce much backward incompatibility (unless
> user changes them through customize interface) since a defconst can
> still be setq'ed and variables will still be used in code base.

I thought that users never ever could change constants. But the docstring of
`defconst' indeed tells that "this constancy is not actually enforced by Emacs
Lisp". Though, can we be sure that this will stay true?

> Opinions?

OK for me.

Best regards,
  Seb

-- 
Sebastien Vauban

[O] Beamer export: How to handle overlayarea

[James Harkins]

Per the beamer user guide, the syntax of the overlayarea environment is:

\begin{overlayarea}{area width}{area height}
environment contents
\end{overlayarea}

I can't figure out how to get the width and height in properly.


From the customize interface, I added overlayarea as follows:


'(org-beamer-environments-extra (quote (("CJK" "Z" "\\begin{CJK}%a%H" 
"\\end{CJK}") ("onlyenv" "O" "\\begin{onlyenv}%a" "\\end{onlyenv}") 
("overlayarea" "Y" "\\begin{overlayarea}%o%a" "\\end{overlayarea}"


And I can plug text into %o using the BEAMER_OPT property:

*** Overlays  :B_overlayarea:
   :PROPERTIES:
   :BEAMER_env: overlayarea
   :BEAMER_OPT: {0.9\textwidth}{0.7\textheight}
   :END:

-->

\begin{overlayarea}[{0.9\textwidth}{0.7\textheight}]

Oh, hello, BEAMER_OPT automatically adds square brackets, how charming.

I guess I can hack up a filter to remove the brackets after overlayarea.

.. 45 minutes after I started writing this email...

I copied someone else's ignoreheading filter and modified it for this 
purpose:


(defun hjh-overlayarea (contents backend info)
 "Remove brackets from options for overlayarea."
 (when (and (org-export-derived-backend-p backend 'latex 'html 'ascii)
 (string-match "begin{overlayarea}\\[\\(.*\\)\\]"
   (downcase contents)))
   (replace-match "begin{overlayarea}\\1" nil nil contents)))

Replace-match's handling of backslashes threw me at first, but this appears 
to work.


Still, I wonder if there shouldn't be, e.g., %O for 
options-without-brackets. Because that was 45 minutes I spent NOT writing 
my slides :-|


Also, side note, [1] seems not to document BEAMER_OPT for environments 
within a frame. Reading this page, you would think you could only use it 
for frames. I had to dig into the source code to find how to populate %o.


hjh

[1] http://orgmode.org/worg/exporters/beamer/ox-beamer.html

[O] function? (was: rotate tables)

[Uwe Brauer]

>> "Michael" == Michael Brand  writes:

   > Hi Uwe
   > On Sun, Oct 20, 2013 at 10:12 PM, Uwe Brauer  wrote:
   >> | 1 | 2 | 3 |
   >> | 4 | 3 | 4 |
   >> 
   >> becomes
   >> 
   >> | 4 | 1 |
   >> | 3 | 2 |
   >> | 4 | 3 |

   > 1) mark table
   > 2) M-x reverse-region
   > 3) with point in the table: M-x org-table-transpose-table-at-point
what's about a small function doing this, like 


(defun org-table-rotate-table  ()
  "Small hack to rotate a table."
  (interactive)
  (if (or (and (boundp 'zmacs-region-active-p) zmacs-region-active-p)
  (and (boundp 'transient-mark-mode) transient-mark-mode 
mark-active))
  (save-restriction
(save-excursion
  (narrow-to-region (point) (mark))
  (goto-char (point-min))
  (reverse-region (point) (mark))
  (org-table-transpose-table-at-point)

Or?

(defun org-table-rotating-table (beg end)  
  "Small hack to rotate a table."
  (interactive "r")
  (save-excursion
(goto-char beg)
(reverse-region beg end)
(org-table-transpose-table-at-point)))



Uwe 


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] Drag images from Firefox to org-mode

[Oleh]

> I suggest to ask for a string with (read-string "URL: " nil nil default),
> offering the content of the clipboard/kill ring/selections as the DEFAULT.
> I think it's better to be explicit when downloading content, and there
> isn't much overhead in asking for a confirmation.

I've moved the clipboard stuff to `org-download-yank'.
`org-download-image' asks for the link now.

> > This can be fixed by adding `org-download-max-filename-length`. When
> > it
> > overflows, just resort to `default-directory' and provide a
> > message/option to fix.
>
> I suggest that the right place for those files is as attachment, and
> that's where customization should happen. The function choosing the
> right place (i.e. org-download--dir) could be turned into a defvar or
> defcustom which could then be set either to #'org-download--dir or
> #'org-attach-dir.

Yes, this should be added.

Oleh