Re: [O] direct link to mails in gmail

On Thu, Oct 20, 2011 at 4:41 AM, Torsten Wagner wrote: > Hi, > I just figured out some kind of very interesting possibility. > All the personal data and security feelings aside, I use a gmail account > since I share it between many different computers. > > In my org-files, I would sometimes like t

Re: [O] direct link to mails in gmail

Hi, Rainer M Krug wrote: > That is really nice - and I used it to link to gmail emails from rtm - but > there is one thing youi should be aware of: the link is only valid, if the > mail keeps the label. As an example: If I copy the link from the inbox, > paste it into an org file, and *then* archi

Re: [O] direct link to mails in gmail

On the mac, you can create links using the message-id (this is used in org-mac-message.el) - I would be surprised if GMail did not have a way to find a message with a specific id...? - Carsten On Oct 20, 2011, at 9:30 AM, Sebastien Vauban wrote: > Hi, > > Rainer M Krug wrote: >> That is reall

Re: [O] Patch for bug in adjusting time ranges in Agenda

Never mind resubmitting, I will take a look at the patch later today. - Carsten On Oct 17, 2011, at 10:50 AM, Niels Giesen wrote: > > > On Sun, Oct 16, 2011 at 6:43 PM, Nick Dokos wrote: > Niels Giesen wrote: > > > *bump* > > > > Has this one slipped through (as I were posting two other pat

Re: [O] direct link to mails in gmail

On Thu, Oct 20, 2011 at 9:30 AM, Sebastien Vauban < wxhgmqzgw...@spammotel.com> wrote: > Hi, > > Rainer M Krug wrote: > > That is really nice - and I used it to link to gmail emails from rtm - > but > > there is one thing youi should be aware of: the link is only valid, if > the > > mail keeps the

Re: [O] [babel] Verbatim output from SQL command

Hi Eric, Eric Schulte wrote: > "Sebastien Vauban" writes: >> Eric Schulte wrote: Babel seems to interpret every *leading space* as *one empty column*. Normal, feature, bug? Is there some workaround to this? I thought stating "scalar" would really completely override any i

Re: [O] direct link to mails in gmail

As a workaround I use the following setup: ;; === org link abbreviations === (setq org-link-abbrev-alist '(("mail" . "https://mail.google.com/a/mydomain.at/#mbox/%s";) )) When I want to link to a mail message in Gmail I click twice into the address line of firefox which conveniently

Re: [O] direct link to mails in gmail

Rainer M Krug gmail.com> writes: > That is really nice - and I used it to link to gmail emails > from rtm - but there is one thing youi should be aware of: the > link is only valid, if the mail keeps the label. As an example: > If I copy the link from the inbox, paste it into an org file, > and

Re: [O] direct link to mails in gmail

Hi Carsten, Carsten Dominik wrote: > On Oct 20, 2011, at 9:30 AM, Sebastien Vauban wrote: >> Sad to say it is also true with Gnus: if you move the mail from one folder >> to another, the link is not valid anymore... >> >> I'd dream being able to even get "shareable" links: be able to make a valid

[O] LATEX_CLASS_OPTIONS in SETUPFILE

Hi, When using #+SETUPFILE and exporting via LaTeX, the LATEX_CLASS_OPTIONS provided in the included file are ignored. With the following two files in the same directory, doing C-c C-e L (org-export to a temporary LaTeX buffer) produces a documentclass with class report (good, as expected) and op

[O] [babel] Expand code is failing on a #+call line

Hi Eric, * Config ** Some file to be ingested Let's say I have this code in a =my-lob.org= file: #+srcname: add-column-in-table(table="", column="", type="", nullability="") #+begin_src sql -- add column `$column' (if column does not exist yet) IF NOT EXISTS (SELECT * FROM INFORM

Re: [O] [babel] Expand code is failing on a #+call line

Hi Seb, This is a minor point, but would you mind structuring your emails with an introduction of pure-prose (no embedded examples), saving the examples for the end (footnotes work well for this). I often find it disjointing to try to ingest large code example while simultaneously trying to figur

Re: [O] Prompt for time when clocking in?

Some progress -- I used Nick's suggestion combined with the org-read-date function. This is my first attempt -- It will prompt you for a time, and clock in to the headline that the cursor is on with that time. (defun njn/clock-in-at-time() (interactive) (setq start-time (org-read-date 't

Re: [O] [babel] Expand code is failing on a #+call line

Hi Eric, Eric Schulte wrote: > This is a minor point, but would you mind structuring your emails with > an introduction of pure-prose (no embedded examples), saving the > examples for the end (footnotes work well for this). I often find it > disjointing to try to ingest large code example while s

Re: [O] Prompt for time when clocking in?

Nathan Neff wrote: > Some progress -- > > I used Nick's suggestion combined with the org-read-date function. > > This is my first attempt -- It will prompt you for a time, and clock > in to the headline that the cursor is on with that time. > > (defun njn/clock-in-at-time() >(interacti

Re: [O] Prompt for time when clocking in?

> Two minor nits: t is a constant so you don't need to quote it; emacs-lisp > mode helps with indentation (putting it in a code block - see below - > in an org file and using C-c ' to edit it works wonderfully). Thanks for your suggestions re: using Emacs to edit lisp code and using the t in lieu

Re: [O] [babel] Expand code is failing on a #+call line

> >> As to this specific question... I am not sure where you are trying to >> expand a code block. It seems as if you are trying to expand a call >> line, but I do not believe that is supposed to be possible. > > As for any other code block, all I want is to see its expanded (instantiated) > versi

[O] [babel] Cannot use R and sh

Hi all, when using R and shell commands, the shell commands are sent to the R buffer. I guess this has something to do with the session argument?! # test.org # #+property: session *R* #+BEGIN_SRC R ## comment 1+1 #+END_SRC #+results: : 2 #+BEGIN_SRC sh ls -a

Re: [O] [babel] Cannot use R and sh

Bernd Weiss wrote: > Hi all, > > when using R and shell commands, the shell commands are sent to the R > buffer. I guess this has something to do with the session argument?! > > # test.org # > > #+property: session *R* > > #+BEGIN_SRC R > ## comment > 1+1 > #+E

Re: [O] [babel] Cannot use R and sh

On 20.10.2011 14:49, Nick Dokos wrote: [...] > AFAIK, the syntax is (note the BABEL and the :session) > > #+BABEL: :session *R* > > With that, I can certainly reproduce what you get and it > is indeed the global session that causes it. If you > want a global session for all the other code block

Re: [O] [babel] Specifying buffer-wide header arguments: #+property vs #+babel (was: Cannot use R and sh)

On 20.10.2011 14:58, Bernd Weiss wrote: [...] > With respect to the "#+BABEL..." syntax, I vaguely remember that this is > deprecated. The Org Mode Manual, however, (still) mentions both ways... > . Earlier this year, Dan D

Re: [O] [babel] Specifying buffer-wide header arguments: #+property vs #+babel

Bernd Weiss writes: > On 20.10.2011 14:58, Bernd Weiss wrote: > > [...] > >> With respect to the "#+BABEL..." syntax, I vaguely remember that this is >> deprecated. The Org Mode Manual, however, (still) mentions both ways... >>

[O] Private flag or property

Hi! I am still in the process of converting (lots!) of old data into Org-mode format. I stumbled over a private-flag PalmOS datebook used to maintain. Is there a *common* way of expressing a private flag/property yet? Or is there no pseudo-standard and I should stick to my «:PRIVATE: True» prop

[O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Hi, I have just pushed up a change to the Org-mode git repository which removes support for #+BABEL lines. Please use the more general #+PROPERTIES lines instead. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/

[O] [PATCH] Check marker is valid before use

lisp/org-agenda.el | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index bf03b68c..f4b8bcbf 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -6784,13 +6784,13 @@ (defun org-agenda-previous-line () (defun org-

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Eric Schulte wrote: > I have just pushed up a change to the Org-mode git repository which > removes support for #+BABEL lines. Please use the more general > #+PROPERTIES lines instead. > Coming late to the dance - sorry. I think that's very confusing. "Property" is an overloaded term in org: w

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Nick Dokos writes: > Eric Schulte wrote: > >> I have just pushed up a change to the Org-mode git repository which >> removes support for #+BABEL lines. Please use the more general >> #+PROPERTIES lines instead. >> > > Coming late to the dance - sorry. I think that's very confusing. > "Property

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Eric Schulte wrote: > Nick Dokos writes: > > > Eric Schulte wrote: > > > >> I have just pushed up a change to the Org-mode git repository which > >> removes support for #+BABEL lines. Please use the more general > >> #+PROPERTIES lines instead. > >> > > > > Coming late to the dance - sorry.

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Hi Nick and Eric, Nick Dokos wrote: > Eric Schulte wrote: >> Nick Dokos writes: >> > Eric Schulte wrote: >> > >> >> I have just pushed up a change to the Org-mode git repository which >> >> removes support for #+BABEL lines. Please use the more general >> >> #+PROPERTIES lines instead. >> > >>

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Whoa -- before this gets more confusing: Eric, did you push up a (new, or at least so far undocumented in the manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien seem to understand you? Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY line or :PROPERTIES: dr

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Christian Moe wrote: > Whoa -- before this gets more confusing: > > Eric, did you push up a (new, or at least so far undocumented in the > manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien > seem to understand you? > > Or was #+PROPERTIES just a typo, and you mean using the #+

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Nick Dokos writes: > Eric Schulte wrote: > >> Nick Dokos writes: >> >> > Eric Schulte wrote: >> > >> >> I have just pushed up a change to the Org-mode git repository which >> >> removes support for #+BABEL lines. Please use the more general >> >> #+PROPERTIES lines instead. >> >> >> > >> >

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Hi Eric, On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte wrote: > 2. The existing #+PROPERTY: line may now be used to specify values for >   header arguments, e.g., > >   #+PROPERTY: results silent > >   would silence all results in the current buffer. > Is the 'results' without a preceding colon

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Hi Eric, Eric Schulte wrote: > Nick Dokos writes: >> Eric Schulte wrote: >>> Nick Dokos writes: >>> > Eric Schulte wrote: >>> > >>> >> I have just pushed up a change to the Org-mode git repository which >>> >> removes support for #+BABEL lines. Please use the more general >>> >> #+PROPERTIES

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Eric Schulte wrote: > ... I've just pushed up what I > consider to be a clean implementation. Put briefly the new behavior is > that "properties may be used to specify header arguments". More > completely... > > 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist. > > 2. The exist

[O] [RFC] Standardized code block keywords

> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION, > #+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd > prefer > deprecating an old form when a better one is found. This point of view has been raised previously both on the mailing list and in t

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

suvayu ali writes: > Hi Eric, > > On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte wrote: >> 2. The existing #+PROPERTY: line may now be used to specify values for >> header arguments, e.g., >> >> #+PROPERTY: results silent >> >> would silence all results in the current buffer. >> > > Is the

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

"Sebastien Vauban" writes: > Hi Eric, > > Eric Schulte wrote: >> Nick Dokos writes: >>> Eric Schulte wrote: Nick Dokos writes: > Eric Schulte wrote: > >> I have just pushed up a change to the Org-mode git repository which >> removes support for #+BABEL lines. Please

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Sebastien Vauban wrote: > I just have one question, as I'm puzzled by the lack of `:' in front of the > "properties": how do we distinguish the argument "value" from the argument > "name"? > > For example, how do we translate, in the new syntax, > > #+BABEL::results output code append > >

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Nick Dokos writes: > Eric Schulte wrote: > >> ... I've just pushed up what I >> consider to be a clean implementation. Put briefly the new behavior is >> that "properties may be used to specify header arguments". More >> completely... >> >> 1. The #+PROPERTIES: (and #+BABEL:) directives no l

[O] org-contacts or bbdb?

Hello, I would like to manage my contacts, so that I can - easily search them - add new email addresses from gnus (summary buffer) - complete email addresses in gnus (message buffer and prompts in mini-buffer) - and perhaps more in the future Could you guide me please, what to choose, org-conta

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Eric Schulte wrote: > > Other than "colon confusion" (having to specify ``:results silent'' on > > the src block header line and ``results silent'' in the #+PROPERTY line > > to get the same behavior), this looks better. Not sure what (if > > anything) can or should be done about the colons. > >

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

Nick Dokos writes: > Eric Schulte wrote: > >> > Other than "colon confusion" (having to specify ``:results silent'' on >> > the src block header line and ``results silent'' in the #+PROPERTY line >> > to get the same behavior), this looks better. Not sure what (if >> > anything) can or should be

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

On Thu, 20 Oct 2011 15:52:42 -0600 Eric Schulte wrote: > suvayu ali writes: > > > Hi Eric, > > > > On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte > > wrote: > >> 2. The existing #+PROPERTY: line may now be used to specify values > >> for header arguments, e.g., > >> > >> #+PROPERTY: results

Re: [O] org-contacts or bbdb?

pmli...@free.fr (Peter Münster) writes: > Hello, > > I would like to manage my contacts, so that I can > - easily search them > - add new email addresses from gnus (summary buffer) > - complete email addresses in gnus (message buffer and prompts in > mini-buffer) > - and perhaps more in the futu

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

Eric Schulte writes: >> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION, >> #+CALL, #+LOB, and SBE, some of which are interchangeable; some >> not. I'd prefer >> deprecating an old form when a better one is found. > > This point of view has been raised previously both

Re: [O] Code block evaluation export bug ?

Nick Dokos writes: > While testing my response to Viktor's question, I ran into a problem. > I used a test file that is slightly modified from a previous post of Tom > Dye's: > > * R tables > > #+TBLNAME: tbl-1 > | column1 | column2 | > |-+-| > | 45 | 34 | > | 77 |

Re: [O] org-contacts or bbdb?

On Fri, Oct 21 2011, Peter Münster wrote: > Hello, > > I would like to manage my contacts, so that I can > - easily search them > - add new email addresses from gnus (summary buffer) > - complete email addresses in gnus (message buffer and prompts in > mini-buffer) > - and perhaps more in the fu

[O] Bill-of-materials

Hi, This is a much better version of the little add-on I've written: Bill-of-materials (org-bom.el) I've used this for over 6 months now, daily. If you ever need to quickly make a quote for a client, or simply make easy to-buy list, this should help you. You can find the code here: http://paste

Re: [O] Code block evaluation export bug ?

Thomas S. Dye wrote: > Aloha Nick, > > I see the same behavior. > Thanks for confirming! I'm not entirely sure but it seems to be R-specific: when babel does variable assignments in org-babel-R-assign-elisp, it creates temp files /tmp/babel-XXX/R-import-YYY and when the tables are written o

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

Thomas S. Dye wrote: > Eric Schulte writes: > > >> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, > >> #+FUNCTION, > >> #+CALL, #+LOB, and SBE, some of which are interchangeable; some > >> not. I'd prefer > >> deprecating an old form when a better one is found. > > > > This

Re: [O] Code block evaluation export bug ?

Nick Dokos wrote: > Thomas S. Dye wrote: > > > > Aloha Nick, > > > > I see the same behavior. > > > > Thanks for confirming! > > I'm not entirely sure but it seems to be R-specific: when babel does > variable assignments in org-babel-R-assign-elisp, it creates temp files > /tmp/babel-XXX/