Re: Column view bugs

[Carsten Dominik <dominik@science.uva.nl>]

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