Org-mode version 4.68

Org-mode version 4.68

[Carsten Dominik]

Org-mode version 4.68 is available at

http://www.astro.uva.nl/~dominik/Tools/org

Enjoy!

- Carsten

Changes in Version 4.68
-----------------------

* Overview

   - Priority handling in the tags view
   - Date/time prompt follows the popup calender, and accepts AM/PM 
times.
   - Standard references like B4 in the spreadsheet.
   - Improvements to the formula editor.
   - C-j does better indentation.
   - Bug fixes

* Details

   - Priority handling in the tags view

     + Agenda lists selected by tag are now sorted by priority.
       Thanks to Andrew Korty for reporting this omission.

   - Improvements to the date/time prompt.

     + When you move (using S-cursor keys) the cursor in the pop-up
       calendar window while responding to a date/time prompt, the
       prompt is updated with the new default date.  Works only under
       Emacs because I don't know how to modify the prompt under
       XEmacs.  Thanks to Bastien for this idea.

     + You can now enter AM/PM times at this prompt.

   - Changes in the spreadsheet

     + You can now also write B4 instead of @4$2 as a reference in
       formulas.  The column references without specified row can be
       written as C& instead of $3.  Such references make formulas
       easier to read and are now the default way how references are
       shown when you edit existing formulas.  To get the old behavior
       back (i.e. only @row$col references), set the variable
       `org-table-use-standard-references' to nil.

       Relative references like @-3$-2 or @II..III continue to use the
       internal format.

   - Changes in the formula editor (the one you get with "C-c '")

     + The formulas are organized in a more logical way.

     + There is now a menu with commands.

     + When starting the formula editor with "C-c '", the cursor
       immediately moves to the formula for the current field.

     + With the cursor on a reference in the formula, you can use
       S-cursor keys to change the field being referenced.

   - C-j indents the following line correctly whe used in a headline
     or in aplain list item.  Thanks to Leo for this suggestion.

   - Bug fixes

     + Flyspell now knows about special org-mode commands.
       Thanks to Vinod Valsalam for reporting this problem, and to
       Andrew Korty for showing how to fix it.

     + Most other bugs discussed recently on emacs-orgmode@gnu.org
       should be fixed, except the problem with non-ASCII characters
       in tags....

Re: Org-mode version 4.68

[Bastien]

Hi Carsten and list,

Carsten Dominik <dominik@science.uva.nl> writes:

> Org-mode version 4.68 is available at
> http://www.astro.uva.nl/~dominik/Tools/org

Great job !  I didn't find time to small, convenient reports, so i send
kind of a "digest", all this happening with latest org-mode (4.68).

* org-publish issues

  C-c C-e A (org-publish-all) won't save the window configuration,
  depending on what buffers are to be saved and published.

  Using timestamps for org-publish is *very convenient*.  But forcing
  re-publication of all the pages (C-u C-c C-e a), makes emacs complains
  about missing directories in ~/.org-timestamps when a project has not
  been normally published first (with C-c C-e P or C-c C-e A).  I think
  forced re-publication should create these directories itself.

* Table navigation / edition

  What about using C-c <return> to insert a plain |---- line *and* go down
  to a cell ?  Currently, it's still bounded to org-insert-heading.

  I was also wondering if it's possible to tell orgtbl-mode not to consider
  each line as a separate row.  For example :

  |---------------------+------------------|
  | Cell#1 Row#1        | Cell#2 Row#1     |
  | (Might this belong  | (...and this     |
  | to the first cell?) | to the second?   |
  |---------------------+------------------|
  | Cell#1 Row#2        | Cell#2 Row#2     |
  | Comment in row#2    | Comment in row#2 |
  |---------------------+------------------|

  would be only *two* rows when exporting to HTML.  (I know i can narrow
  columns, but sometimes it's convenient to actually see the content of all
  the cells...)

* Exporting text before the first heading ?

  It seems that text before the first heading is not exported.  Using
  #+TEXT: might help, but #+TEXT: does not understand links.  Is that
  intentional ?

* *[[link]]* are not boldified when exported to HTML.

* .ics export bugs

  I'm not sure about the definition of X-WR-CALNAME: in .ics files (i can't
  find it in RFCs), but i assume it's the "name" of the calendar.  It's
  currently set up to "OrgMode".  I think it should be the actual name of
  the org file, or a default name for combined agendas.

  Another tiny thing: if the descriptive part of a link (within a heading)
  contains a comma (`,') then the entry in the .ics file will ignore what
  comes before the comma.

Thanks again !

-- 
Bastien

Re: Org-mode version 4.68

[Carsten Dominik]

Hi Bastien,

On Mar 16, 2007, at 12:11, Bastien wrote:
> * org-publish issues
>
>   C-c C-e A (org-publish-all) won't save the window configuration,
>   depending on what buffers are to be saved and published.
>
>   Using timestamps for org-publish is *very convenient*.  But forcing
>   re-publication of all the pages (C-u C-c C-e a), makes emacs 
> complains
>   about missing directories in ~/.org-timestamps when a project has not
>   been normally published first (with C-c C-e P or C-c C-e A).  I think
>   forced re-publication should create these directories itself.

I have forwarded this mail to David O'Toole, to find out if he still
feels responsible for changes in org-publish.  Lets wait if he responds.

>
> * Table navigation / edition
>
>   What about using C-c <return> to insert a plain |---- line *and* go 
> down
>   to a cell ?  Currently, it's still bounded to org-insert-heading.

Do you mean down to a cell in the current column, or down to the first
cell in the row below the newly inserted hline?

>   I was also wondering if it's possible to tell orgtbl-mode not to 
> consider
>   each line as a separate row.  For example :
>
>   |---------------------+------------------|
>   | Cell#1 Row#1        | Cell#2 Row#1     |
>   | (Might this belong  | (...and this     |
>   | to the first cell?) | to the second?   |
>   |---------------------+------------------|
>   | Cell#1 Row#2        | Cell#2 Row#2     |
>   | Comment in row#2    | Comment in row#2 |
>   |---------------------+------------------|
>
>   would be only *two* rows when exporting to HTML.  (I know i can 
> narrow
>   columns, but sometimes it's convenient to actually see the content 
> of all
>   the cells...)

No.  The org-mode tables are deeply rooted on the fact that a cell
covers only a single line.  Much of the easy and speed in operating the
table editor depends on it, and I don't want to compromise on that.

You have two options:

1.  Make a table using the table.el package.  The HTML exporter does
     export such tables correctly.  table.el is really good at what
     it does, which is creating tables just like your example above.
     But when you use it, you immediately feel the overhead that is
     associated with a complex table structure like this.

2.  You can spread the content of a long cell over several lines
     by hand, org-mode helps with several commands like M-RET to
     split a field in the middle and put the second half into the
     next row, or C-c C-q which wraps a long cell over a couple
     of rows.  However, these commands do not change the fact that
     org-mode sees each line as a new row and will export like that.

> * Exporting text before the first heading ?
>
>   It seems that text before the first heading is not exported.  Using
>   #+TEXT: might help, but #+TEXT: does not understand links.  Is that
>   intentional ?

I guess this is not very well though-out, and maybe it would be good
to simply export the text before the first heading.
That TEXT is not HTML processed I would also consider as
a bug, but I know that some have made clever use of this bug
to insert custom HTML into a file.  This is now no loger
necessary since you can embed protected HTML with special commands.

Hmmm, not clear to me how exactly this should be done.  Should we
cast a vote for exporting text before the first heading?

> * *[[link]]* are not boldified when exported to HTML.

No it does not.  Should it?  What is the purpose of making
some links bold? Are you thinking about internal or
external links?  Would CSS maybe be a better place to address
formatting of links?

> * .ics export bugs
>
>   I'm not sure about the definition of X-WR-CALNAME: in .ics files (i 
> can't
>   find it in RFCs), but i assume it's the "name" of the calendar.  It's
>   currently set up to "OrgMode".  I think it should be the actual name 
> of
>   the org file, or a default name for combined agendas.

Sounds resonable.

>   Another tiny thing: if the descriptive part of a link (within a 
> heading)
>   contains a comma (`,') then the entry in the .ics file will ignore 
> what
>   comes before the comma.

I cannot reproduce this.  Could you make an example file and show the
.ics entry you get?  Thanks!

- Carsten

Re: Org-mode version 4.68

[Bastien]

Carsten Dominik <dominik@science.uva.nl> writes:

> I have forwarded this mail to David O'Toole, to find out if he still
> feels responsible for changes in org-publish.  Lets wait if he responds.

Okay. I'll see if i'm able to go through org-publish and track this down.

>>   What about using C-c <return> to insert a plain |---- line *and* go
>> down
>>   to a cell ?  Currently, it's still bounded to org-insert-heading.
>
> Do you mean down to a cell in the current column, or down to the first
> cell in the row below the newly inserted hline?

Down to the first cell in the row below the newly inserted hline.

> You have two options:
>
> 1.  Make a table using the table.el package.  

I'll try this one in cases where i don't want to use the narrowing
workaround (which is usually fine).

> I guess this is not very well though-out, and maybe it would be good
> to simply export the text before the first heading.

Definitely.  +1 vote! 

>> * *[[link]]* are not boldified when exported to HTML.
>
> No it does not.  Should it?  What is the purpose of making some links
> bold? Are you thinking about internal or external links?  Would CSS maybe
> be a better place to address formatting of links?

I was using links with the #+LINK system, looking for words in wikipedia
like this : [[wikipedia:Word][Word]].  And then highlighting some words in
the text, some of them beeing *also* links.  But you're right, no need to
fontified links more than necessary.

> I cannot reproduce this.  Could you make an example file and show the
> ics entry you get?  Thanks!

Er.  I cannot reproduce this anymore.  BTW, the main problem is that links
in headings are exported as it: [[...][...]].  I think we should just keep
the descriptive part of links in iCal.

Thanks,

-- 
Bastien

Re: Org-mode version 4.68

[David O'Toole]

Hi everyone, 

I'll set aside some time this week to straighten out these
problems. Sorry I haven't been too vocal on the orgmode list lately, I
have been working on other things.

Is there anything else people want me to add/fix in org-publish while
I am at it? 

Carsten Dominik <dominik@science.uva.nl> writes:

> On Mar 16, 2007, at 12:11, Bastien wrote:
>> * org-publish issues
>>
>>   C-c C-e A (org-publish-all) won't save the window configuration,
>>   depending on what buffers are to be saved and published.
>>
>>   Using timestamps for org-publish is *very convenient*.  But forcing
>>   re-publication of all the pages (C-u C-c C-e a), makes emacs
>> complains
>>   about missing directories in ~/.org-timestamps when a project has not
>>   been normally published first (with C-c C-e P or C-c C-e A).  I think
>>   forced re-publication should create these directories itself.
>
> I have forwarded this mail to David O'Toole, to find out if he still
> feels responsible for changes in org-publish.  Lets wait if he responds.

-- 
David O'Toole 
dto@gnu.org
http://dto.freeshell.org/notebook/

Re: Org-mode version 4.68

[Carsten Dominik]

On Mar 16, 2007, at 19:39, Bastien wrote:
>>>   What about using C-c <return> to insert a plain |---- line *and* go
>>> down
>>>   to a cell ?  Currently, it's still bounded to org-insert-heading.
>>
>> Do you mean down to a cell in the current column, or down to the first
>> cell in the row below the newly inserted hline?
>
> Down to the first cell in the row below the newly inserted hline.

Hmmm, yes, why not.


>> I guess this is not very well though-out, and maybe it would be good
>> to simply export the text before the first heading.
>
> Definitely.  +1 vote!

So far this is still the only vote ........

>> I cannot reproduce this.  Could you make an example file and show the
>> ics entry you get?  Thanks!
>
> Er.  I cannot reproduce this anymore.  BTW, the main problem is that 
> links
> in headings are exported as it: [[...][...]].  I think we should just 
> keep
> the descriptive part of links in iCal.

I fixed this a while ago, but I see now that I only did this for
calendar entries, not for TODO entries. Will be fixed in the next 
version.

- Carsten

Re: Org-mode version 4.68

[Alex Fu]

Dear all,

On Fri, 16 Mar 2007 13:08:33 -0400, Carsten Dominik  
<dominik@science.uva.nl> wrote:

>> * Exporting text before the first heading ?
>>
>>   It seems that text before the first heading is not exported.  Using
>>   #+TEXT: might help, but #+TEXT: does not understand links.  Is that
>>   intentional ?
>
> I guess this is not very well though-out, and maybe it would be good
> to simply export the text before the first heading.
> That TEXT is not HTML processed I would also consider as
> a bug, but I know that some have made clever use of this bug
> to insert custom HTML into a file.  This is now no loger
> necessary since you can embed protected HTML with special commands.

Note that the #+HTML: and #+BEGIN_HTML...#+END_HTML directives are not  
(yet) a replacement for inserting literal html as it can be done using  
#+TEXT:.  As far as I've noticed, #+TEXT: inserts html (or any other text)  
before the first heading (before the <h2> in the resulting html file),  
something the #+HTML directives can't do, since the effect of placing it  
before the first heading is null, as it is not exported.

I don't expect to use Org as a full-featured publishing engine.  Still,  
the following example represents a very specific use of #+TEXT: that I  
need for implementing file-specific site navigation (as opposed to  
project-specific, which in this case is configured using :preamble in  
`org-publish-project-alist').  These are the relevant lines in the org  
file:

-----
   #+TEXT: @</p>@<p class="marginpar">@<a href="intro.html">Return to  
introduction@</a>@<p>
   * Sonata for Unaccompanied Achilles
     ^ will be exported as <h2> after <p class="marginpar">...
-----

AFAIK, I can't use #+HTML: to insert that snippet before the <h2>, or  
first level 'org' heading, which is what I need.

> Hmmm, not clear to me how exactly this should be done.  Should we
> cast a vote for exporting text before the first heading?

This is my idea: if the text before the first heading were exported and  
that included the #+HTML: directives, it would be one way (out of perhaps  
a handful) to avoid having to use the #+HTML: and #+TEXT: directives for  
the same purpose -- exporting literal html.  In the end, for literal html  
we'd just use #+HTML: anywhere in the file, while #+TEXT: could be  
reserved for a different purpose.

Vote: +1

But the final decision should consider other (broader) aspects...

Kind regards.

-- 
Alex Fu

Re: Org-mode version 4.68

[Carsten Dominik]

On Mar 19, 2007, at 15:21, Alex Fu wrote:

> Dear all,
>
> On Fri, 16 Mar 2007 13:08:33 -0400, Carsten Dominik 
> <dominik@science.uva.nl> wrote:
>
>>> * Exporting text before the first heading ?
>>>
>>>   It seems that text before the first heading is not exported.  Using
>>>   #+TEXT: might help, but #+TEXT: does not understand links.  Is that
>>>   intentional ?
>>
>> I guess this is not very well though-out, and maybe it would be good
>> to simply export the text before the first heading.
>> That TEXT is not HTML processed I would also consider as
>> a bug, but I know that some have made clever use of this bug
>> to insert custom HTML into a file.  This is now no loger
>> necessary since you can embed protected HTML with special commands.
>
> Note that the #+HTML: and #+BEGIN_HTML...#+END_HTML directives are not 
> (yet) a replacement for inserting literal html as it can be done using 
> #+TEXT:.  As far as I've noticed, #+TEXT: inserts html (or any other 
> text) before the first heading (before the <h2> in the resulting html 
> file), something the #+HTML directives can't do, since the effect of 
> placing it before the first heading is null, as it is not exported.

This will change.  In the future, #+TEXT: lines will be fully
processed like any other buffer line, I consider that fact that
is was not processed so far as a bug. On the other hand,
constructs like the following will be allowed:

#+TEXT: Processed text iwth *bold* words
#+TEXT: #+BEGIN_HTML
#+TEXT: <a href="...">unprocessed HTML code</a>
#+TEXT: #+END_HTML
#+TEXT: /This/ will be processed again

There will also be an option to export the text before the
first headline, in which case the #+TEXT prefix is not necessary.

- Carsten

Re: Org-mode version 4.68

[Carsten Dominik]

On Mar 16, 2007, at 12:11, Bastien wrote:

> * .ics export bugs
>
>   I'm not sure about the definition of X-WR-CALNAME: in .ics files (i 
> can't
>   find it in RFCs), but i assume it's the "name" of the calendar.  It's
>   currently set up to "OrgMode".  I think it should be the actual name 
> of
>   the org file, or a default name for combined agendas.

The name for the *combined* export (using all org-agenda-files)
is given by `org-icalendar-combined-name', default "OrgMode".
For individual files, CATEGORY in that file is is used, either
the first #+CATEGORY in the file, or something derived the file
name.   Still sounds like the right choice for me.

- Carsten

Re: Org-mode version 4.68

[Bastien]

Carsten Dominik <dominik@science.uva.nl> writes:

> The name for the *combined* export (using all org-agenda-files)
> is given by `org-icalendar-combined-name', default "OrgMode".

Wasn't aware of that.  It fixes the problem for me now.  Thanks!

-- 
Bastien

Re: Org-mode version 4.68

[Leo]

On 2007-03-13, Carsten Dominik said:

>   - Improvements to the date/time prompt.
>
>     + When you move (using S-cursor keys) the cursor in the pop-up
>       calendar window while responding to a date/time prompt, the
>       prompt is updated with the new default date.  Works only under
>       Emacs because I don't know how to modify the prompt under
>       XEmacs.  Thanks to Bastien for this idea.
>
>     + You can now enter AM/PM times at this prompt.

I always found it painful to set up a time range in org. For example,
if I want to allocate one hour from 12:00-13:00 to work on project
A. I have to use 'C-c .' twice. Is there any suggestion on improving
this situation?

At the moment, it seems to me enhancing this feature to support time
range 12:00-13:00 on the same date very inconvenient i.e. if user type
in 12:00-13:00 and mouse click today it should inserts:

<2007-03-22 Thu 12:00>--<2007-03-22 Thu 13:00>

Or maybe we should just support:

<2007-03-22 Thu 12:00-13:00>


What do you think?

Best,
-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: Org-mode version 4.68

[T. V. Raman]

would be nice to be able to invoke org-publish on a region of
text and have it replaced by say html.

>>>>> "David" == David O'Toole <dto@gnu.org> writes:
    David> Hi everyone,
    David> 
    David> I'll set aside some time this week to straighten out
    David> these problems. Sorry I haven't been too vocal on the
    David> orgmode list lately, I have been working on other
    David> things.
    David> 
    David> Is there anything else people want me to add/fix in
    David> org-publish while I am at it?
    David> 
    David> Carsten Dominik <dominik@science.uva.nl> writes:
    David> 
    >> On Mar 16, 2007, at 12:11, Bastien wrote:
    >>> * org-publish issues
    >>> 
    >>> C-c C-e A (org-publish-all) won't save the window
    >>> configuration, depending on what buffers are to be saved
    >>> and published.
    >>> 
    >>> Using timestamps for org-publish is *very convenient*.
    >>> But forcing re-publication of all the pages (C-u C-c C-e
    >>> a), makes emacs complains about missing directories in
    >>> ~/.org-timestamps when a project has not been normally
    >>> published first (with C-c C-e P or C-c C-e A).  I think
    >>> forced re-publication should create these directories
    >>> itself.
    >> 
    >> I have forwarded this mail to David O'Toole, to find out
    >> if he still feels responsible for changes in org-publish.
    >> Lets wait if he responds.
    David> 
    David> -- David O'Toole dto@gnu.org
    David> http://dto.freeshell.org/notebook/
    David> 
    David> 
    David> _______________________________________________
    David> Emacs-orgmode mailing list Emacs-orgmode@gnu.org
    David> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Org-mode version 4.68

[Carsten Dominik]

On Mar 31, 2007, at 23:58, T. V. Raman wrote:

>
> would be nice to be able to invoke org-publish on a region of
> text and have it replaced by say html.

This will, in 4.75, be M-x org-replace-region-by-html,
a global command that can be invoked in any buffer to
replace the current region with HTML, assuming that the region was
in org-mode syntax before.

- Carsten