* Column view bugs
@ 2007-10-13 6:44 Scott Jaderholm
2007-10-13 9:28 ` Carsten Dominik
2007-10-13 16:13 ` Bastien
0 siblings, 2 replies; 9+ messages in thread
From: Scott Jaderholm @ 2007-10-13 6:44 UTC (permalink / raw)
To: org-mode
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Column view bugs 2007-10-13 6:44 Column view bugs Scott Jaderholm @ 2007-10-13 9:28 ` Carsten Dominik 2007-10-13 13:50 ` Bastien 2007-10-15 21:46 ` Daniel J. Sinder 2007-10-13 16:13 ` Bastien 1 sibling, 2 replies; 9+ messages in thread From: Carsten Dominik @ 2007-10-13 9:28 UTC (permalink / raw) To: Scott Jaderholm; +Cc: org-mode 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Column view bugs 2007-10-13 9:28 ` Carsten Dominik @ 2007-10-13 13:50 ` Bastien 2007-10-14 19:54 ` Vagn Johansen 2007-10-15 21:46 ` Daniel J. Sinder 1 sibling, 1 reply; 9+ messages in thread From: Bastien @ 2007-10-13 13:50 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Column view bugs 2007-10-13 13:50 ` Bastien @ 2007-10-14 19:54 ` Vagn Johansen 2007-10-16 0:03 ` Bastien 0 siblings, 1 reply; 9+ messages in thread From: Vagn Johansen @ 2007-10-14 19:54 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: Column view bugs 2007-10-14 19:54 ` Vagn Johansen @ 2007-10-16 0:03 ` Bastien 2007-10-16 16:41 ` Vagn Johansen 0 siblings, 1 reply; 9+ messages in thread From: Bastien @ 2007-10-16 0:03 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Column view bugs 2007-10-16 0:03 ` Bastien @ 2007-10-16 16:41 ` Vagn Johansen 2007-10-18 20:43 ` Vagn Johansen 0 siblings, 1 reply; 9+ messages in thread From: Vagn Johansen @ 2007-10-16 16:41 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Column view bugs 2007-10-16 16:41 ` Vagn Johansen @ 2007-10-18 20:43 ` Vagn Johansen 0 siblings, 0 replies; 9+ messages in thread From: Vagn Johansen @ 2007-10-18 20:43 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Column view bugs 2007-10-13 9:28 ` Carsten Dominik 2007-10-13 13:50 ` Bastien @ 2007-10-15 21:46 ` Daniel J. Sinder 1 sibling, 0 replies; 9+ messages in thread From: Daniel J. Sinder @ 2007-10-15 21:46 UTC (permalink / raw) To: Carsten Dominik; +Cc: org-mode 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Column view bugs 2007-10-13 6:44 Column view bugs Scott Jaderholm 2007-10-13 9:28 ` Carsten Dominik @ 2007-10-13 16:13 ` Bastien 1 sibling, 0 replies; 9+ messages in thread From: Bastien @ 2007-10-13 16:13 UTC (permalink / raw) To: emacs-orgmode "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-10-18 20:44 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-10-13 6:44 Column view bugs Scott Jaderholm 2007-10-13 9:28 ` Carsten Dominik 2007-10-13 13:50 ` Bastien 2007-10-14 19:54 ` Vagn Johansen 2007-10-16 0:03 ` Bastien 2007-10-16 16:41 ` Vagn Johansen 2007-10-18 20:43 ` Vagn Johansen 2007-10-15 21:46 ` Daniel J. Sinder 2007-10-13 16:13 ` Bastien
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).