emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Column view bugs


From: Carsten Dominik
Subject: Re: [Orgmode] Column view bugs
Date: Sat, 13 Oct 2007 11:28:56 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]