Column view bugs

Column view bugs

[Scott Jaderholm]

Carsten,

I took a closer look at column view today and really liked what I saw.
It seems to have gotten a lot better since I tried it on 5.01, but it
may just be that I understood the implementation this time around.

I think it works very well and I am very surprised it hasn't gotten
more use. I did find a few bugs however, and I think this may be what
has deterred people from using it more.

Bug #1
You cannot set the property with C-c C-x p in column view unless the
properties drawer is already created. It will say text is read-only
after prompting you for property and value.

Since you can edit properties fine if there is a property drawer, it
seems like we should be able to just create a property drawer if it
doesn't already exist.

Feature Request #1
Is it hard to allow setting TODO and tag setting with normal commands
while on the heading in column view?

Bug #2
M-f M-b jump around in a confusing way in column view. Maybe just make
them like C-f and C-b?

Feature Request #2
Is it hard to allow editing of headings with e in column view?

Bug #3
C-c C-x p fails if there isn't a newline after the current heading.
Put * Heading at bottom of file and try adding a property. I get Wrong
type argument: number-or-marker-p, nil

Feature Request #3
I think a currency sum type would be a nice addition.

Bug #4
I don't think column summaries work without a column width. I get
"Format specifier doesn't match argument type" with the following

* Equipment
  :PROPERTIES:
  :COLUMNS:  %32ITEM %Cost{+}
  :END:
** Item 1
   :PROPERTIES:
   :Cost:     10
   :END:

Bug #5
If * Heading is the first thing in a file, pressing e in column view
on that will give Args out of range errors.

Bug #6
If you have a blank line in buffer and then this
* Heading
** Subheading

If there is no newline after Subheading and you try to use e on any of
it's columns you will get an End of buffer message

Bug #7
With the example above, if there is a newline after Subheading, you
can edit priority and tags fine but editing TODO on Subheading or
Heading butcher the "* Heading" line. Setting TODO on Heading will
replace "* Heading" with " TODO ng" and give a message "before first
heading." Setting TODO on Subheading will give similar results.

Thought #1
I'm not sure having the column headings at the top of the buffer is
the best place if you have multiple level 1 headings in one file and
the level 1 heading you're editing in column view is not the first. In
tall windows with long files you the column headings can turn up
really far from the actual columns. I don't know, maybe it is easiest
to put it at the top, but you might think about putting it above the
level 1 heading of the list in column view or even right above the
first list in column view.

Feature Request #4
Is having the column view print practical? What about export?

Bug #8
M-S-right is really nice, but it doesn't work if you haven't already
defined your COLUMNS. Either it shouldn't prompt for info or it should
create a COLUMNS for you (my preference).

Bug #9
M-S-left asks if you want to remove column, such as PRIORITY, but it
doesn't actually do it when you're not using your own COLUMNS

Bug #10
M-right and M-left behave differently depending on whether COLUMNS is
defined or not.

Thanks!
--Scott

Re: Column view bugs

[Carsten Dominik]

Hi Scott,

On Oct 13, 2007, at 8:44, Scott Jaderholm wrote:

> Carsten,
>
> I took a closer look at column view today and really liked what I saw.
> It seems to have gotten a lot better since I tried it on 5.01, but it
> may just be that I understood the implementation this time around.

Maybe both.

> I think it works very well and I am very surprised it hasn't gotten
> more use.

I guess it needs some discussion here, and a screencast :-)

> I did find a few bugs however, and I think this may be what
> has deterred people from using it more.

Quite possible.

>
> Bug #1
> You cannot set the property with C-c C-x p in column view unless the
> properties drawer is already created. It will say text is read-only
> after prompting you for property and value.

Yes, this is a bug.
>
> Feature Request #1
> Is it hard to allow setting TODO and tag setting with normal commands
> while on the heading in column view?

No, that should be possible.

>
> Bug #2
> M-f M-b jump around in a confusing way in column view. Maybe just make
> them like C-f and C-b?

Good idea.

Question back: TAB does still cycle visibility in column view,
even though this looks like a table and one might expect
that tab moves to the next field.  Any thoughts on this?

>
> Feature Request #2
> Is it hard to allow editing of headings with e in column view?

No really, but not trivial either.  I'll tae a look at it.

>
> Bug #3
> C-c C-x p fails if there isn't a newline after the current heading.
> Put * Heading at bottom of file and try adding a property. I get Wrong
> type argument: number-or-marker-p, nil

ok.

>
> Feature Request #3
> I think a currency sum type would be a nice addition.

How is that different from {+} ?  Prefixing the number with
a currency symbol?

>
> Bug #4
> I don't think column summaries work without a column width. I get
> "Format specifier doesn't match argument type" with the following
>
> * Equipment
>   :PROPERTIES:
>   :COLUMNS:  %32ITEM %Cost{+}
>   :END:
> ** Item 1
>    :PROPERTIES:
>    :Cost:     10
>    :END:
>

Hmmm.

> Bug #5
> If * Heading is the first thing in a file, pressing e in column view
> on that will give Args out of range errors.

ok.

>
> Bug #6
> If you have a blank line in buffer and then this
> * Heading
> ** Subheading
>
> If there is no newline after Subheading and you try to use e on any of
> it's columns you will get an End of buffer message

ok

>
> Bug #7
> With the example above, if there is a newline after Subheading, you
> can edit priority and tags fine but editing TODO on Subheading or
> Heading butcher the "* Heading" line. Setting TODO on Heading will
> replace "* Heading" with " TODO ng" and give a message "before first
> heading." Setting TODO on Subheading will give similar results.

^$%#^$

> Thought #1
> I'm not sure having the column headings at the top of the buffer is
> the best place if you have multiple level 1 headings in one file and
> the level 1 heading you're editing in column view is not the first. In
> tall windows with long files you the column headings can turn up
> really far from the actual columns. I don't know, maybe it is easiest
> to put it at the top, but you might think about putting it above the
> level 1 heading of the list in column view or even right above the
> first list in column view.

The column heading is not at the beginning of the buffer.  It is in a
special header line, similar to the mode line below the buffer.  The 
means
that you can recenter and scroll the column view table at will, the
header line will stay fixed.  For example, go to the first column line
and press `C-0 C-l'.

> Feature Request #4
> Is having the column view print practical? What about export?

Yes, clearly important missing features.  What should we have?

One interesting possibility would be a dynamic block that
captures the column view as an Org-mode table.  Other proposals?

>
> Bug #8
> M-S-right is really nice, but it doesn't work if you haven't already
> defined your COLUMNS. Either it shouldn't prompt for info or it should
> create a COLUMNS for you (my preference).

The problem here is, where to create it.  Globally for the entire buffer
with a #+COLUMNS line is probably the best?  Of should this be a 
property
of the top-level entry in the column view?  The disadvantage of the 
second
possibility is that you might create COLUMNS properties by accident 
without
noticing.  I guess it will be #+COLUMNS.

>
> Bug #9
> M-S-left asks if you want to remove column, such as PRIORITY, but it
> doesn't actually do it when you're not using your own COLUMNS

Yes, same issue as before.

>
> Bug #10
> M-right and M-left behave differently depending on whether COLUMNS is
> defined or not.

Again, the same problem.

This will take some time to fix, thanks for your (hopefully)
exhaustive list.

- Carsten

Re: Column view bugs

[Bastien]

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

>> M-f M-b jump around in a confusing way in column view. Maybe just make
>> them like C-f and C-b?
>
> Good idea.
>
> Question back: TAB does still cycle visibility in column view,
> even though this looks like a table and one might expect
> that tab moves to the next field.  Any thoughts on this?

I'm not expecting TAB to jump from field to field here, but maybe others
would. A possible trade-off: do the normal cycling when at the beginning
of the line, jump among fields otherwise?

>> Is having the column view print practical? What about export?
>
> Yes, clearly important missing features.  What should we have?
>
> One interesting possibility would be a dynamic block that
> captures the column view as an Org-mode table.  

That would definitely be nice!

> The problem here is, where to create it.  Globally for the entire
> buffer with a #+COLUMNS line is probably the best?

Yes.

While we are at this, what would people think of a new {%} summary type
for column view?

  {%}  Progress status, [100%] if all children are in a DONE state.

-- 
Bastien

Re: Column view bugs

[Vagn Johansen]

Bastien <bzg@altern.org> writes:

> While we are at this, what would people think of a new {%} summary type
> for column view?
>
>   {%}  Progress status, [100%] if all children are in a DONE state.

That is nice.

I could also see a use for a state-dependent {:}. Display the sum of
times and also the sum of times for tasks that are DONE. E.g. for
adding time-estimates and measuring progress. Or maybe add up the
not-DONEs to show the remaining time.

-- 
Vagn Johansen

Re: Re: Column view bugs

[Bastien]

Vagn Johansen <ozymandias.dk@gmail.com> writes:

> I could also see a use for a state-dependent {:}. Display the sum of
> times and also the sum of times for tasks that are DONE. E.g. for
> adding time-estimates and measuring progress. Or maybe add up the
> not-DONEs to show the remaining time.

Isn't this already achievable with a clever todo/archive structure?

See for example this:

* Project 1
  :PROPERTIES:
  :COLUMNS:  %20ITEM %4Time_Spent{:}
  :ARCHIVE:  ::** Archives for project 1
  :Time_Spent: 2:00
  :END:

** Task 1
   :PROPERTIES:
   :Time_Spent: 1:15
   :END:

** Archives for project 1
   :PROPERTIES:
   :COLUMNS:  %20ITEM %4Time_Spent{:}
   :Time_Spent: 0:45
   :END:

*** DONE Task 2
    :PROPERTIES:
    :Time_Spent: 0:45
    :ARCHIVE_TIME: 2007-10-16 mar 01:00
    :ARCHIVE_FILE: ~/test.org
    :ARCHIVE_CATEGORY: test
    :END:

Turning the column view will display a Time_Spent property both for
"Project 1" and for "Archives for project 1", which means that you can
"display the sum of times and also the sum of times for tasks that are
DONE."

-- 
Bastien

Re: Column view bugs

[Vagn Johansen]

Bastien <bzg@altern.org> writes:

> Vagn Johansen <ozymandias.dk@gmail.com> writes:
>
>> I could also see a use for a state-dependent {:}. Display the sum of
>> times and also the sum of times for tasks that are DONE. E.g. for
>> adding time-estimates and measuring progress. Or maybe add up the
>> not-DONEs to show the remaining time.
>
> Isn't this already achievable with a clever todo/archive structure?

Sort of. But I do not want to be forced to use a specific structure.

Also it gives incorrect sums if you havee subproject with with mixed
TODO and DONE tasks.

-- 
Vagn Johansen

Re: Column view bugs

[Vagn Johansen]

Vagn Johansen <ozymandias.dk@gmail.com> writes:

> Bastien <bzg@altern.org> writes:
>
>> Vagn Johansen <ozymandias.dk@gmail.com> writes:
>>
>>> I could also see a use for a state-dependent {:}. Display the sum of
>>> times and also the sum of times for tasks that are DONE. E.g. for
>>> adding time-estimates and measuring progress. Or maybe add up the
>>> not-DONEs to show the remaining time.
>>
>> Isn't this already achievable with a clever todo/archive structure?
>
> Sort of. But I do not want to be forced to use a specific structure.
>
> Also it gives incorrect sums if you havee subproject with with mixed
> TODO and DONE tasks.
>

I discovered that is easy to just copy the Time_Estimate value  to
Time_Spent for those tasks that are DONE.


(save-excursion
  (goto-char (point-min))
  ;; For each node
  (while (re-search-forward (concat "^" outline-regexp) nil t)
    ;; If task is done and there is no Time_Spent property
    (if (and (equal (org-entry-get (point) "TODO") "DONE")
          (not (org-entry-get (point) "Time_Spent")))
      ;; Add Time_Spent property with the value from the
      ;; Time_Estimate property if available or 999000
      (org-entry-put (point) "Time_Spent"
        (or (org-entry-get (point) "Time_Estimate") "999000")))))

-- 
Vagn Johansen

Re: Column view bugs

[Daniel J. Sinder]

On 10/13/2007 02:28 AM, Carsten Dominik wrote:
>> Feature Request #4
>> Is having the column view print practical? What about export?
> 
> Yes, clearly important missing features.  What should we have?
> 
> One interesting possibility would be a dynamic block that
> captures the column view as an Org-mode table.  Other proposals?

I raised the question about column view export early on:
http://thread.gmane.org/gmane.emacs.orgmode/2295

I think that thread headed in the wrong direction, with some
suggestions for dynamic HTML type stuff for collapsing/expanding --
too complicated and certainly beyond my knowledge.  But I think
going to an Org-mode table might be the "easy" way out, since table
exporting is already quite good.

For what it's worth, this is a feature I'd use.

Thanks,
Dan

(Still enjoying org-mode but too busy to keep up with most of the
new features and the voluminous emacs-orgmode emails)

Re: Column view bugs

[Bastien]

"Scott Jaderholm" <jaderholm@gmail.com> writes:

> Bug #9
> M-S-left asks if you want to remove column, such as PRIORITY, but it
> doesn't actually do it when you're not using your own COLUMNS
>
> Bug #10
> M-right and M-left behave differently depending on whether COLUMNS is
> defined or not.

I noticed that the cursor is (again) able to move at the right of the
last column -- being outside the fields, at the end of the line.

I guess it is intentional: the idea is to let you add a column at this
place.  But since I reported this behavior as a *bug* before (and that
bug was then fixed), I'm just double-checking.

Thanks,

-- 
Bastien