Saving column views in agenda

Saving column views in agenda

[Matthew Lundin]

I often use dynamic blocks to save/export column views in org-mode
files. Does anyone know of a similar way to export/save a column view
from the agenda? When I write the agenda to a file, it naturally
writes only the text (not the column overlay).

Regards,
Matt

Re: Saving column views in agenda

[Carsten Dominik]

Hi Matthew,

this is currently not possible.

You could try to use the mapping API to do something yourself.

What is your use-case?

- Carsten

On Dec 8, 2008, at 6:52 AM, Matthew Lundin wrote:

>
> I often use dynamic blocks to save/export column views in org-mode
> files. Does anyone know of a similar way to export/save a column view
> from the agenda? When I write the agenda to a file, it naturally
> writes only the text (not the column overlay).
>
> Regards,
> Matt
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Saving column views in agenda

[mdl]

Hi Carsten,

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

> Hi Matthew,
>
> this is currently not possible.
>
> You could try to use the mapping API to do something yourself.
>
> What is your use-case?
>
> - Carsten

Thanks for the quick response. I use the agenda to filter column views
via property searches. Let's say I'm keeping track of my spending with
the following outline:

#+COLUMNS: %20ITEM %10TIMESTAMP %20spendtype %10amount{$}

* December Spending
** Week One
*** Grocery Store [2008-12-01 Mon]
    :PROPERTIES:
    :amount: 56.77
    :spendtype: food:
    :END:
*** Athletic club [2008-12-02 Tue]
    :PROPERTIES:
    :amount: 75.00
    :spendtype: health
    :END:
** Week Two 
*** Restaurant [2008-12-08 Mon]
    :PROPERTIES:
    :amount: 30.67
    :spendtype: food
    :END:

With such an outline (obviously much longer and more complex in
reality), I use columns and dynamic blocks to give me a quick overview
(with sums) of spending by week. I also use the agenda to filter these
views by spendtype, so that I can see, for instance, the sum of how
much I spent on food each week/month/year. Currently, I can use column
view in the agenda to generate sums, but I cannot export the column
view for permanent reference or for sharing with others.

I suppose this functionality could be achieved in a few other ways as
well:

1) A dynamic block that captures a column view, but with a parameter
that filters for TAG, property, etc.  

2) A column view combined with a sparse tree that sums the amounts of
only the visible items. Currently, when "summary-type" is specified,
the column view adds all items in the outline hierarchy, regardless of
their visibility. (Of course, if this method were possible, one would
still have to devise a way to export the filtered column view.)

3) A filter for tables that one could apply to the exported column
view. (E.g., show only rows in which "Column 3 = x" and calculate only
the visible items.) 

There is, of course, the likelihood that #1, #2, or #3 already exist
and that I have simply missed something in the manual. Please do let
me know if this is the case. I also realize that I could simply
create subheadings for each spending type (e.g., *** Food) that would
create the desired effect in the column view. But as data becomes more
complex, it would be nice to generate these filtered views
dynamically.

To sum up a long reply: I am curious whether it is possible to create
exportable, dynamically filtered data in column views, in which the
sum created in a "summary-type" column is recalculated when items are
filtered. (I suppose this would count as part of org-mode's
"spreadsheet" functionality.)

Thanks, as always, for such a wonderful program. 
 
Matt
   
>
> On Dec 8, 2008, at 6:52 AM, Matthew Lundin wrote:
>
>>
>> I often use dynamic blocks to save/export column views in org-mode
>> files. Does anyone know of a similar way to export/save a column view
>> from the agenda? When I write the agenda to a file, it naturally
>> writes only the text (not the column overlay).
>>
>> Regards,
>> Matt
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Saving column views in agenda

[Carsten Dominik]

Hi Matt,

this is an interesting problem.  I can see three ways to go forward:

1. To indeed export agenda column view, but maybe it would actually
    be nicer to capture it into a table somewhere.

2. I believe I can relatively easily make it possible to capture
    in an Org buffer from a sparse tree, or even using a full
    match string with tags and properties.  However, I don't think
    that I can make he partial sums work in this way, and I don't
    actually think that you'd want your parent properties filled with
    temporary, partial sums.  Maybe the way to go would be to capture
    a sparse tree, and then to do the summing using calc formulas on the
    captured table, would that work?  I am not sure tight now if such
    formulas persist, but I believe it works for clock tables, so we
    could make it work for column view capture as well.

3. Maybe what would be even beter is to build on Eric Schultes collector
    function an make something that would create a custom able from
    selected properties of matched entries.  That could then be
    incorporated into a dynamic block so that it can be easily updated.
    Eric, would you like to comment?

- Carsten



On Dec 8, 2008, at 4:51 PM, mdl@imapmail.org wrote:

>
> Hi Carsten,
>
> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> Hi Matthew,
>>
>> this is currently not possible.
>>
>> You could try to use the mapping API to do something yourself.
>>
>> What is your use-case?
>>
>> - Carsten
>
> Thanks for the quick response. I use the agenda to filter column views
> via property searches. Let's say I'm keeping track of my spending with
> the following outline:
>
> #+COLUMNS: %20ITEM %10TIMESTAMP %20spendtype %10amount{$}
>
> * December Spending
> ** Week One
> *** Grocery Store [2008-12-01 Mon]
>    :PROPERTIES:
>    :amount: 56.77
>    :spendtype: food:
>    :END:
> *** Athletic club [2008-12-02 Tue]
>    :PROPERTIES:
>    :amount: 75.00
>    :spendtype: health
>    :END:
> ** Week Two
> *** Restaurant [2008-12-08 Mon]
>    :PROPERTIES:
>    :amount: 30.67
>    :spendtype: food
>    :END:
>
> With such an outline (obviously much longer and more complex in
> reality), I use columns and dynamic blocks to give me a quick overview
> (with sums) of spending by week. I also use the agenda to filter these
> views by spendtype, so that I can see, for instance, the sum of how
> much I spent on food each week/month/year. Currently, I can use column
> view in the agenda to generate sums, but I cannot export the column
> view for permanent reference or for sharing with others.
>
> I suppose this functionality could be achieved in a few other ways as
> well:
>
> 1) A dynamic block that captures a column view, but with a parameter
> that filters for TAG, property, etc.
>
> 2) A column view combined with a sparse tree that sums the amounts of
> only the visible items. Currently, when "summary-type" is specified,
> the column view adds all items in the outline hierarchy, regardless of
> their visibility. (Of course, if this method were possible, one would
> still have to devise a way to export the filtered column view.)
>
> 3) A filter for tables that one could apply to the exported column
> view. (E.g., show only rows in which "Column 3 = x" and calculate only
> the visible items.)
>
> There is, of course, the likelihood that #1, #2, or #3 already exist
> and that I have simply missed something in the manual. Please do let
> me know if this is the case. I also realize that I could simply
> create subheadings for each spending type (e.g., *** Food) that would
> create the desired effect in the column view. But as data becomes more
> complex, it would be nice to generate these filtered views
> dynamically.
>
> To sum up a long reply: I am curious whether it is possible to create
> exportable, dynamically filtered data in column views, in which the
> sum created in a "summary-type" column is recalculated when items are
> filtered. (I suppose this would count as part of org-mode's
> "spreadsheet" functionality.)
>
> Thanks, as always, for such a wonderful program.
>
> Matt
>
>>
>> On Dec 8, 2008, at 6:52 AM, Matthew Lundin wrote:
>>
>>>
>>> I often use dynamic blocks to save/export column views in org-mode
>>> files. Does anyone know of a similar way to export/save a column  
>>> view
>>> from the agenda? When I write the agenda to a file, it naturally
>>> writes only the text (not the column overlay).
>>>
>>> Regards,
>>> Matt
>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Remember: use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Saving column views in agenda

[Matthew Lundin]

Hi Carsten,

Thanks for your quick and thoughtful response.

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

> Hi Matt,
>
> this is an interesting problem.  I can see three ways to go forward:
>
> 1. To indeed export agenda column view, but maybe it would actually
>    be nicer to capture it into a table somewhere.

I'd agree that capturing agenda column view in in a table would be
even better than export, so that further calculations could be
performed on the data.

>
> 2. I believe I can relatively easily make it possible to capture
>    in an Org buffer from a sparse tree, or even using a full
>    match string with tags and properties.  However, I don't think
>    that I can make he partial sums work in this way, and I don't
>    actually think that you'd want your parent properties filled with
>    temporary, partial sums.  Maybe the way to go would be to capture
>    a sparse tree, and then to do the summing using calc formulas on the
>    captured table, would that work?  I am not sure tight now if such
>    formulas persist, but I believe it works for clock tables, so we
>    could make it work for column view capture as well.
>
This would be another very nice option. There would be no need for
partial sums in the column view itself so long as calculations could
be performed in the exported table.

> 3. Maybe what would be even beter is to build on Eric Schultes collector
>    function an make something that would create a custom able from
>    selected properties of matched entries.  That could then be
>    incorporated into a dynamic block so that it can be easily updated.
>    Eric, would you like to comment?

I was only vaguely aware of org-collector. I'll have to take a closer
look. I'm assuming that a dynamic block function based on
org-collector would be the most robust option, since one could then
choose create new subsets of data by changing the parameters. Is that
correct?

It occurred to me that an ideal scenario would be to combine #2 and
#3. Would it be possible to capture a sparse tree column view as a
dynamic block containing parameters that could subsequently be
changed/updated?

Thanks so much for considering these ideas. Of course, please consider
all these requests simply as wishlist items. I'm working on learning
emacs lisp, but I'm afraid it will be a while before I can contribute
anything to org.

Best,

Matt

>
> - Carsten
>
>
>
> On Dec 8, 2008, at 4:51 PM, mdl@imapmail.org wrote:
>
>>
>> Hi Carsten,
>>
>> Carsten Dominik <dominik@science.uva.nl> writes:
>>
>>> Hi Matthew,
>>>
>>> this is currently not possible.
>>>
>>> You could try to use the mapping API to do something yourself.
>>>
>>> What is your use-case?
>>>
>>> - Carsten
>>
>> Thanks for the quick response. I use the agenda to filter column views
>> via property searches. Let's say I'm keeping track of my spending with
>> the following outline:
>>
>> #+COLUMNS: %20ITEM %10TIMESTAMP %20spendtype %10amount{$}
>>
>> * December Spending
>> ** Week One
>> *** Grocery Store [2008-12-01 Mon]
>>    :PROPERTIES:
>>    :amount: 56.77
>>    :spendtype: food:
>>    :END:
>> *** Athletic club [2008-12-02 Tue]
>>    :PROPERTIES:
>>    :amount: 75.00
>>    :spendtype: health
>>    :END:
>> ** Week Two
>> *** Restaurant [2008-12-08 Mon]
>>    :PROPERTIES:
>>    :amount: 30.67
>>    :spendtype: food
>>    :END:
>>
>> With such an outline (obviously much longer and more complex in
>> reality), I use columns and dynamic blocks to give me a quick overview
>> (with sums) of spending by week. I also use the agenda to filter these
>> views by spendtype, so that I can see, for instance, the sum of how
>> much I spent on food each week/month/year. Currently, I can use column
>> view in the agenda to generate sums, but I cannot export the column
>> view for permanent reference or for sharing with others.
>>
>> I suppose this functionality could be achieved in a few other ways as
>> well:
>>
>> 1) A dynamic block that captures a column view, but with a parameter
>> that filters for TAG, property, etc.
>>
>> 2) A column view combined with a sparse tree that sums the amounts of
>> only the visible items. Currently, when "summary-type" is specified,
>> the column view adds all items in the outline hierarchy, regardless of
>> their visibility. (Of course, if this method were possible, one would
>> still have to devise a way to export the filtered column view.)
>>
>> 3) A filter for tables that one could apply to the exported column
>> view. (E.g., show only rows in which "Column 3 = x" and calculate only
>> the visible items.)
>>
>> There is, of course, the likelihood that #1, #2, or #3 already exist
>> and that I have simply missed something in the manual. Please do let
>> me know if this is the case. I also realize that I could simply
>> create subheadings for each spending type (e.g., *** Food) that would
>> create the desired effect in the column view. But as data becomes more
>> complex, it would be nice to generate these filtered views
>> dynamically.
>>
>> To sum up a long reply: I am curious whether it is possible to create
>> exportable, dynamically filtered data in column views, in which the
>> sum created in a "summary-type" column is recalculated when items are
>> filtered. (I suppose this would count as part of org-mode's
>> "spreadsheet" functionality.)
>>
>> Thanks, as always, for such a wonderful program.
>>
>> Matt
>>
>>>
>>> On Dec 8, 2008, at 6:52 AM, Matthew Lundin wrote:
>>>
>>>>
>>>> I often use dynamic blocks to save/export column views in org-mode
>>>> files. Does anyone know of a similar way to export/save a column
>>>> view
>>>> from the agenda? When I write the agenda to a file, it naturally
>>>> writes only the text (not the column overlay).
>>>>
>>>> Regards,
>>>> Matt
>>>>
>>>>
>>>> _______________________________________________
>>>> Emacs-orgmode mailing list
>>>> Remember: use `Reply All' to send replies to the list.
>>>> Emacs-orgmode@gnu.org
>>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Saving column views in agenda

[Eric Schulte]

Matthew Lundin <mdl@imapmail.org> writes:

>> 3. Maybe what would be even beter is to build on Eric Schultes collector
>>    function an make something that would create a custom able from
>>    selected properties of matched entries.  That could then be
>>    incorporated into a dynamic block so that it can be easily updated.
>>    Eric, would you like to comment?
>
> I was only vaguely aware of org-collector. I'll have to take a closer
> look. I'm assuming that a dynamic block function based on
> org-collector would be the most robust option, since one could then
> choose create new subsets of data by changing the parameters. Is that
> correct?
>

Hi,

Sorry about the slow reply.

I believe org-collector could be helpful in this scenario.  In response
to this thread I've changed org-collector so that it will preserve
#+TBLFM lines.  The latest version is available here.

http://github.com/eschulte/org-contrib/raw/master/org-collector.el

Using this version, the example below works for me.  Notice that while
org-collector can perform arbitrary elisp functions over the properties
of any single header it can't --currently-- run functions over multiple
headers, which is why the #+TBLFM line is required.  Hopefully this
works for you.

Best -- Eric

* Example

#+BEGIN: propview :id "december" :cols (ITEM amount spendtype (if (string= spendtype "food") amount 0))
| "ITEM"                           | "amount" | "spendtype" | "(if (string= spendtype \"food\") amount 0)" |
|----------------------------------+----------+-------------+----------------------------------------------|
| "Week One"                       |        0 | 0           |                                            0 |
| "Grocery Store [2008-12-01 Mon]" |    56.77 | "food"      |                                        56.77 |
| "Athletic club [2008-12-02 Tue]" |     75.0 | "health"    |                                            0 |
| "Week Two "                      |        0 | 0           |                                            0 |
| "Restaurant [2008-12-08 Mon]"    |    30.67 | "food"      |                                        30.67 |
|                                  |          |             |                                        87.44 |
#+TBLFM: @7$4=vsum(@2..@6)
#+END:


** December Spending
   :PROPERTIES:
   :ID:       december
   :END:

*** Week One
**** Grocery Store [2008-12-01 Mon]
     :PROPERTIES:
     :amount: 56.77
     :spendtype: food
     :END:
**** Athletic club [2008-12-02 Tue]
     :PROPERTIES:
     :amount: 75.00
     :spendtype: health
     :END:
*** Week Two 
**** Restaurant [2008-12-08 Mon]
     :PROPERTIES:
     :amount: 30.67
     :spendtype: food
     :END:

Re: Saving column views in agenda

[Eric Schulte]

Matthew Lundin <mdl@imapmail.org> writes:

> Eric,
>
> Thanks so much. The updated org-collector works beautifully. This is a
> very nice way to perform calculations on subsets of data. I don't
> suppose there's any chance of generating a table that contains only
> the items in the subset (e.g., only items in which string= spendtype
> "food")?
>

Hi Matthew,

Good idea.  I've added a :conds parameter which can do just that, see
the example below.  Notice that :conds should be a list of tests, not
just one single test, if this proves awkward it would be easy to add
a :cond parameter which doesn't require a list.

One issue with this setup, is that it's not clear what a stable way
would be to specify the #+TBLFM line.  Since the size of the table could
vary the field in which the sum should be placed could move around.
With the table below a #+TBLFM line like this

  #+TBLFM: @II+1$2=vsum(@I+1..@II-1)

would work, but currently org-table does not allow the @I style
references before the = sign in the table formula.  I wonder if this
would be hard difficult to change?

Thanks -- Eric



* Example

#+BEGIN: propview :id "december" :conds ((string= spendtype "food")) :cols (ITEM amount)
| "ITEM"                           | "amount" |
|----------------------------------+----------|
| "Grocery Store [2008-12-01 Mon]" |    56.77 |
| "Restaurant [2008-12-08 Mon]"    |    30.67 |
|----------------------------------+----------|
|                                  |    87.44 |
#+TBLFM: @4$2=vsum(@I+1..@II-1)
#+END:

** December Spending
   :PROPERTIES:
   :ID:       december
   :END:

*** Week One
**** Grocery Store [2008-12-01 Mon]
     :PROPERTIES:
     :amount: 56.77
     :spendtype: food
     :END:
**** Athletic club [2008-12-02 Tue]
     :PROPERTIES:
     :amount: 75.00
     :spendtype: health
     :END:
*** Week Two 
**** Restaurant [2008-12-08 Mon]
     :PROPERTIES:
     :amount: 30.67
     :spendtype: food
     :END:

Re: Saving column views in agenda

[mdl]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Matthew,
>
> Good idea.  I've added a :conds parameter which can do just that, see
> the example below.  Notice that :conds should be a list of tests, not
> just one single test, if this proves awkward it would be easy to add
> a :cond parameter which doesn't require a list.
>

Thanks for the update. This is fantastic! It makes it very easy to put
a subset of property data in a nice, clean table and thus adds
powerful spreadsheet functionality to org-mode.

> One issue with this setup, is that it's not clear what a stable way
> would be to specify the #+TBLFM line.  Since the size of the table could
> vary the field in which the sum should be placed could move around.
> With the table below a #+TBLFM line like this
>
>   #+TBLFM: @II+1$2=vsum(@I+1..@II-1)
>
> would work, but currently org-table does not allow the @I style
> references before the = sign in the table formula.  I wonder if this
> would be hard difficult to change?
>

I considered the same thing when I inquired about selecting for a
particular condition--namely, that it would interfere the #+TBLFM
formula.

If allowing for the @I reference before the equal is not possible, I
wonder whether another notation could be added to org-table that would
designate the last field in a column (or row)---since such fields are
often used to show the results of calculations. That would enable one
to create a stable formula that would survive changes to the number of
rows in a table. (In other words, one could add rows to the table and
still ensure that the formula is attached to the last row.) I'd agree,
however, that begin able to use @I before the equal would be
preferable, because then (as far as I understand it) one could
designate arbitrary "fixed" positions in tables with hlines.

Thanks,

Matt

Re: Saving column views in agenda

[Matthew Lundin]

Hi Eric,

The addition of the :conds parameter to org-collector, the first
example you provided (the one that zeroed out the amount for all items
not "food") now results in 1 rather than 0 in the headings. (Example
below.)

Thanks for taking a look at this.

Best,

Matt

* Example
#+BEGIN: propview :id "december" :cols (ITEM amount spendtype (if (string= spendtype "food") amount 0))
| "ITEM"                           | "amount" | "spendtype" | "(if (string= spendtype \"food\") amount 0)" |
|----------------------------------+----------+-------------+----------------------------------------------|
| "Week One"                       |        1 | 1           |                                            1 |
| "Grocery Store [2008-12-01 Mon]" |    56.77 | "food"      |                                        56.77 |
| "Athletic club [2008-12-02 Tue]" |     75.0 | "health"    |                                            0 |
| "Week Two "                      |        1 | 1           |                                            1 |
| "Restaurant [2008-12-08 Mon]"    |    30.67 | "food"      |                                        30.67 |
|----------------------------------+----------+-------------+----------------------------------------------|
|                                  |          |             |                                              |
#+END:

** December Spending
   :PROPERTIES:
   :ID:       december
   :END:

*** Week One
**** Grocery Store [2008-12-01 Mon]
     :PROPERTIES:
     :amount: 56.77
     :spendtype: food
     :END:
**** Athletic club [2008-12-02 Tue]
     :PROPERTIES:
     :amount: 75.00
     :spendtype: health
     :END:
*** Week Two 
**** Restaurant [2008-12-08 Mon]
     :PROPERTIES:
     :amount: 30.67
     :spendtype: food
     :END:

Re: Saving column views in agenda

[Carsten Dominik]

On Dec 11, 2008, at 8:09 PM, Eric Schulte wrote:

> Matthew Lundin <mdl@imapmail.org> writes:
>
>> Eric,
>>
>> Thanks so much. The updated org-collector works beautifully. This  
>> is a
>> very nice way to perform calculations on subsets of data. I don't
>> suppose there's any chance of generating a table that contains only
>> the items in the subset (e.g., only items in which string= spendtype
>> "food")?
>>
>
> Hi Matthew,
>
> Good idea.  I've added a :conds parameter which can do just that, see
> the example below.  Notice that :conds should be a list of tests, not
> just one single test, if this proves awkward it would be easy to add
> a :cond parameter which doesn't require a list.
>
> One issue with this setup, is that it's not clear what a stable way
> would be to specify the #+TBLFM line.  Since the size of the table  
> could
> vary the field in which the sum should be placed could move around.
> With the table below a #+TBLFM line like this
>
>  #+TBLFM: @II+1$2=vsum(@I+1..@II-1)
>
> would work, but currently org-table does not allow the @I style
> references before the = sign in the table formula.  I wonder if this
> would be hard difficult to change?

Hi Eric,

I do like this syntax, and I am sure that would be possible,
but I do not oversee it, it would be quite complicated and
would have to be changed in multiple locations, messing with
well-tested regular expressions etc.  I would need
significant quiet time, which I don't hve right now.
See also my reply to Matt's message.

- Carsten

>
>
> Thanks -- Eric
>
>
>
> * Example
>
> #+BEGIN: propview :id "december" :conds ((string= spendtype  
> "food")) :cols (ITEM amount)
> | "ITEM"                           | "amount" |
> |----------------------------------+----------|
> | "Grocery Store [2008-12-01 Mon]" |    56.77 |
> | "Restaurant [2008-12-08 Mon]"    |    30.67 |
> |----------------------------------+----------|
> |                                  |    87.44 |
> #+TBLFM: @4$2=vsum(@I+1..@II-1)
> #+END:
>
> ** December Spending
>   :PROPERTIES:
>   :ID:       december
>   :END:
>
> *** Week One
> **** Grocery Store [2008-12-01 Mon]
>     :PROPERTIES:
>     :amount: 56.77
>     :spendtype: food
>     :END:
> **** Athletic club [2008-12-02 Tue]
>     :PROPERTIES:
>     :amount: 75.00
>     :spendtype: health
>     :END:
> *** Week Two
> **** Restaurant [2008-12-08 Mon]
>     :PROPERTIES:
>     :amount: 30.67
>     :spendtype: food
>     :END:
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Saving column views in agenda

[Carsten Dominik]

On Dec 11, 2008, at 10:34 PM, mdl@imapmail.org wrote:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Hi Matthew,
>>
>> Good idea.  I've added a :conds parameter which can do just that, see
>> the example below.  Notice that :conds should be a list of tests, not
>> just one single test, if this proves awkward it would be easy to add
>> a :cond parameter which doesn't require a list.
>>
>
> Thanks for the update. This is fantastic! It makes it very easy to put
> a subset of property data in a nice, clean table and thus adds
> powerful spreadsheet functionality to org-mode.
>
>> One issue with this setup, is that it's not clear what a stable way
>> would be to specify the #+TBLFM line.  Since the size of the table  
>> could
>> vary the field in which the sum should be placed could move around.
>> With the table below a #+TBLFM line like this
>>
>>  #+TBLFM: @II+1$2=vsum(@I+1..@II-1)
>>
>> would work, but currently org-table does not allow the @I style
>> references before the = sign in the table formula.  I wonder if this
>> would be hard difficult to change?
>>
>
> I considered the same thing when I inquired about selecting for a
> particular condition--namely, that it would interfere the #+TBLFM
> formula.
>
> If allowing for the @I reference before the equal is not possible, I
> wonder whether another notation could be added to org-table that would
> designate the last field in a column (or row)---since such fields are
> often used to show the results of calculations. That would enable one
> to create a stable formula that would survive changes to the number of
> rows in a table. (In other words, one could add rows to the table and
> still ensure that the formula is attached to the last row.) I'd agree,
> however, that begin able to use @I before the equal would be
> preferable, because then (as far as I understand it) one could
> designate arbitrary "fixed" positions in tables with hlines.


Yes, this is not the first time that a request for a last-line
reference has come up.  But the connection with org-collector.el
really seems to need this, so I finally took a look.

I needed only a single line edit to make @0 refer to the last line.
Up in the git repo now.

- Carsten












>
>
> Thanks,
>
> Matt
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Saving column views in agenda

[Carsten Dominik]

On Dec 11, 2008, at 10:34 PM, mdl@imapmail.org wrote:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Hi Matthew,
>>
>> Good idea.  I've added a :conds parameter which can do just that, see
>> the example below.  Notice that :conds should be a list of tests, not
>> just one single test, if this proves awkward it would be easy to add
>> a :cond parameter which doesn't require a list.
>>
>
> Thanks for the update. This is fantastic! It makes it very easy to put
> a subset of property data in a nice, clean table and thus adds
> powerful spreadsheet functionality to org-mode.
>
>> One issue with this setup, is that it's not clear what a stable way
>> would be to specify the #+TBLFM line.  Since the size of the table  
>> could
>> vary the field in which the sum should be placed could move around.
>> With the table below a #+TBLFM line like this
>>
>>  #+TBLFM: @II+1$2=vsum(@I+1..@II-1)
>>
>> would work, but currently org-table does not allow the @I style
>> references before the = sign in the table formula.  I wonder if this
>> would be hard difficult to change?
>>
>
> I considered the same thing when I inquired about selecting for a
> particular condition--namely, that it would interfere the #+TBLFM
> formula.
>
> If allowing for the @I reference before the equal is not possible, I
> wonder whether another notation could be added to org-table that would
> designate the last field in a column (or row)---since such fields are
> often used to show the results of calculations. That would enable one
> to create a stable formula that would survive changes to the number of
> rows in a table. (In other words, one could add rows to the table and
> still ensure that the formula is attached to the last row.)


One more remark to this last statement.  For interactive use, if you  
add lines to a table using the correct commands like S-M-down, the  
formulas will be automatically adjusted so that a pointer to a field  
below this inserted line will still reference that same field.

Ah, I would like to rewrite the entire table code to make this  
spreadsheet stuff easier to maintain and improve......


> I'd agree,
> however, that begin able to use @I before the equal would be
> preferable, because then (as far as I understand it) one could
> designate arbitrary "fixed" positions in tables with hlines.
>
> Thanks,
>
> Matt
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Saving column views in agenda

[Carsten Dominik]

On Dec 11, 2008, at 10:34 PM, mdl@imapmail.org wrote:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Hi Matthew,
>>
>> Good idea.  I've added a :conds parameter which can do just that, see
>> the example below.  Notice that :conds should be a list of tests, not
>> just one single test, if this proves awkward it would be easy to add
>> a :cond parameter which doesn't require a list.
>>
>
> Thanks for the update. This is fantastic! It makes it very easy to put
> a subset of property data in a nice, clean table and thus adds
> powerful spreadsheet functionality to org-mode.
>
>> One issue with this setup, is that it's not clear what a stable way
>> would be to specify the #+TBLFM line.  Since the size of the table  
>> could
>> vary the field in which the sum should be placed could move around.
>> With the table below a #+TBLFM line like this
>>
>>  #+TBLFM: @II+1$2=vsum(@I+1..@II-1)
>>
>> would work, but currently org-table does not allow the @I style
>> references before the = sign in the table formula.  I wonder if this
>> would be hard difficult to change?
>>
>
> I considered the same thing when I inquired about selecting for a
> particular condition--namely, that it would interfere the #+TBLFM
> formula.
>
> If allowing for the @I reference before the equal is not possible, I
> wonder whether another notation could be added to org-table that would
> designate the last field in a column (or row)---since such fields are
> often used to show the results of calculations. That would enable one
> to create a stable formula that would survive changes to the number of
> rows in a table. (In other words, one could add rows to the table and
> still ensure that the formula is attached to the last row.) I'd agree,
> however, that begin able to use @I before the equal would be
> preferable, because then (as far as I understand it) one could
> designate arbitrary "fixed" positions in tables with hlines.

And one final remark, sorry for the trickling answers
to this single email....:
You can also use named fields for this purpose.  See the
section about advanced feature in the manual.

- Carsten

Re: Saving column views in agenda

[Matthew Lundin]

Carsten Dominik <dominik@science.uva.nl> writes:
>
>
> Yes, this is not the first time that a request for a last-line
> reference has come up.  But the connection with org-collector.el
> really seems to need this, so I finally took a look.
>
> I needed only a single line edit to make @0 refer to the last line.
> Up in the git repo now.
>
> - Carsten

Carsten,

Thanks so much for adding this feature. As always, I'm very grateful
for the time and care you take in responding to user requests.

Eric,

Thanks again for adding the :conds parameter to org-collector. It does
exactly what I was looking for.

Best,

Matt