* Arbitrary lisp functions in column-attributes
@ 2013-10-28 17:00 Mark Edgington
2013-11-04 12:08 ` Bastien
0 siblings, 1 reply; 11+ messages in thread
From: Mark Edgington @ 2013-10-28 17:00 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]
Hello all,
I would really appreciate it if it were possible to specify an arbitrary
lisp function to process node-properties when creating a column view. For
example, you can currently have something like:
* Top node for columns view
:PROPERTIES:
:COLUMNS: %25ITEM %TAGS %PRIORITY %TODO
:END:
But I'd like to be able to do something like:
:COLUMNS: %ITEM{fn:process_item} %TAGS %PRIORITY %TODO
which would pass the ITEM property's value as a single argument to the
process_item function. The returned value/string of the function would be
what appears in the column view.
Of course it would be good if one could also use a lambda expression in
place of the function name.
Does this sound like something worth working on? I would certainly have
various uses for such functionality, so I imagine it would be useful to
others as well.
Regards,
Mark
[-- Attachment #2: Type: text/html, Size: 1052 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Arbitrary lisp functions in column-attributes
2013-10-28 17:00 Arbitrary lisp functions in column-attributes Mark Edgington
@ 2013-11-04 12:08 ` Bastien
2013-11-04 17:56 ` Mark Edgington
0 siblings, 1 reply; 11+ messages in thread
From: Bastien @ 2013-11-04 12:08 UTC (permalink / raw)
To: Mark Edgington; +Cc: emacs-orgmode
Hi Mark,
Mark Edgington <edgimar@gmail.com> writes:
> But I'd like to be able to do something like:
>
> :COLUMNS: %ITEM{fn:process_item} %TAGS %PRIORITY %TODO
FWIW, I'd be inclined to say this is a bit *too much* -- but I'm
curious to see if others have the same need.
--
Bastien
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Arbitrary lisp functions in column-attributes
2013-11-04 12:08 ` Bastien
@ 2013-11-04 17:56 ` Mark Edgington
2013-11-05 21:06 ` Bastien
0 siblings, 1 reply; 11+ messages in thread
From: Mark Edgington @ 2013-11-04 17:56 UTC (permalink / raw)
To: emacs-orgmode
Bastien <bzg <at> gnu.org> writes:
>
> FWIW, I'd be inclined to say this is a bit *too much* -- but I'm
> curious to see if others have the same need.
>
Hi Bastien,
What about it seems too much? Or put differently, what do you think would
be the negative effects of having something like this possible?
From my (obviously biased) point of view, making it available would mean
that the dynamic column view becomes much more flexible, and it would reduce
the need in the future for lots of new hard-coded features/functions to be
added to the related org-mode code. Instead, features can start out as
functions which people create and share, and if they become popular enough
among many people, they can be incorporated as a "built-in" feature that
comes with org-mode, or as a contributed module.
Regards,
Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Arbitrary lisp functions in column-attributes
2013-11-04 17:56 ` Mark Edgington
@ 2013-11-05 21:06 ` Bastien
2013-11-06 5:02 ` Mark Edgington
0 siblings, 1 reply; 11+ messages in thread
From: Bastien @ 2013-11-05 21:06 UTC (permalink / raw)
To: Mark Edgington; +Cc: emacs-orgmode
Hi Mark,
Mark Edgington <edgimar@gmail.com> writes:
> What about it seems too much? Or put differently, what do you think would
> be the negative effects of having something like this possible?
One possible negative effect I can see is that users have to be extra
careful what type of output such functions will produce, so that this
output can be used by a summary type.
> From my (obviously biased) point of view, making it available would mean
> that the dynamic column view becomes much more flexible, and it would reduce
> the need in the future for lots of new hard-coded features/functions to be
> added to the related org-mode code. Instead, features can start out as
> functions which people create and share, and if they become popular enough
> among many people, they can be incorporated as a "built-in" feature that
> comes with org-mode, or as a contributed module.
Yes, I understand this, and my objection is not really technical: this
is just a vague intuition of what traps users may fall in. But I'd say
that we should try every other ways (like Babel, org-collector, etc.)
before going down this road -- and someone will have to implement this
anyway... but that's just not me :) (I don't want to close a door.)
Best,
--
Bastien
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Arbitrary lisp functions in column-attributes
2013-11-05 21:06 ` Bastien
@ 2013-11-06 5:02 ` Mark Edgington
2013-11-06 8:20 ` Bastien
0 siblings, 1 reply; 11+ messages in thread
From: Mark Edgington @ 2013-11-06 5:02 UTC (permalink / raw)
To: emacs-orgmode
Hi Bastien,
On Tue, Nov 5, 2013 at 4:06 PM, Bastien <bzg@gnu.org> wrote:
> One possible negative effect I can see is that users have to be extra
> careful what type of output such functions will produce, so that this
> output can be used by a summary type.
Wouldn't the output of a function be something mutually exclusive with
summary types? In other words, a column can be defined to use a
summary type, or it could be defined (with the proposed idea) as the
output of a function, but not both at the same time.
> ... we should try every other ways (like Babel, org-collector, etc.)
> before going down this road -- and someone will have to implement this
> anyway... but that's just not me :) (I don't want to close a door.)
After playing around some more with org-collector, I found that it can
in fact do some of the things I had previously thought it couldn't do,
like specifying custom values for column headers. The documentation
on worg for org-collector seems a bit lacking, in that it doesn't
cover all of the available properties you can use on a "#+BEGIN:
propview ..." line. I had to read through the code to identify some
additional properties I could use.
Nonetheless, it seems that org-collector doesn't make the level of a
headline available as a property, so there isn't a good way to achieve
an equivalent to column-view's :maxlevel property in org-collector.
If this were made possible in org-collector, it would be able to do
(at least) most of what column-view can do. But, there are also the
:hlines, :vlines, and :skip-empty-rows properties for column-view,
each which don't appear to have an equivalent with org-collector.
One other difference has to do with the "default value" when a
property isn't defined -- org-collector sets the default value to 0,
while for column-view it seems to be an empty string. I therefore
modified org-collector to make it easier to set this default value
when defining a dynamic block:
--- org-collector.el
+++ org-coll-new.el
@@ -121,6 +121,7 @@
(scope (plist-get params :scope))
(noquote (plist-get params :noquote))
(colnames (plist-get params :colnames))
+ (defaultval (plist-get params :defaultval))
(content-lines (org-split-string (plist-get params :content) "\n"))
id table line pos)
(save-excursion
@@ -133,9 +134,10 @@
(t (error "Cannot find entry with :ID: %s" id))))
(unless (eq id 'global) (org-narrow-to-subtree))
(setq stringformat (if noquote "%s" "%S"))
- (setq table (org-propview-to-table
+ (let ((org-propview-default-value (if defaultval defaultval
org-propview-default-value)))
+ (setq table (org-propview-to-table
(org-propview-collect cols stringformat conds match
scope inherit
- (if colnames colnames cols)) stringformat))
+ (if colnames colnames cols)) stringformat)))
(widen))
(setq pos (point))
(when content-lines
Regards,
Mark
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Arbitrary lisp functions in column-attributes
2013-11-06 5:02 ` Mark Edgington
@ 2013-11-06 8:20 ` Bastien
0 siblings, 0 replies; 11+ messages in thread
From: Bastien @ 2013-11-06 8:20 UTC (permalink / raw)
To: Mark Edgington; +Cc: emacs-orgmode
Hi Mark,
Mark Edgington <edgimar@gmail.com> writes:
> Wouldn't the output of a function be something mutually exclusive with
> summary types? In other words, a column can be defined to use a
> summary type, or it could be defined (with the proposed idea) as the
> output of a function, but not both at the same time.
So your proposal boils down to allowing arbitrary summary types,
with user defined functions? If so, that seems useful and consistent
to me, I may have a look at some point.
> One other difference has to do with the "default value" when a
> property isn't defined -- org-collector sets the default value to 0,
> while for column-view it seems to be an empty string. I therefore
> modified org-collector to make it easier to set this default value
> when defining a dynamic block:
Thanks -- can you submit the patch following the guidelines on
http://orgmode.org/worg/org-contribute.html (using git format-patch
and adding a commit message with a proper ChangeLog) ?
Thanks in advance,
--
Bastien
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Arbitrary lisp functions in column-attributes
@ 2013-10-31 16:41 Mark Edgington
2013-10-31 17:56 ` Aaron Ecay
0 siblings, 1 reply; 11+ messages in thread
From: Mark Edgington @ 2013-10-31 16:41 UTC (permalink / raw)
To: emacs-orgmode
Hello all,
Since the formatting on my earlier post was bad, I'm re-posting this
with a bit more information:
I would really appreciate it if it were possible to specify an
arbitrary lisp function to process node-properties when creating a
column view. Currently it is possible to have something like:
* Top node for columns view
:PROPERTIES:
:COLUMNS: %25ITEM %TAGS %PRIORITY %TODO
:END:
But I'd like to be able to do something like:
:COLUMNS: %ITEM{fn:process_item}(My Column Heading Name) %TAGS
%PRIORITY %TODO
which would pass the ITEM property's value as a single argument to the
process_item function. The returned value/string of the function
would be what appears in the column view.
Of course one should also be able to use a lambda expression in place
of the function name.
Does this sound like something worth working on? I would certainly
have various uses for such functionality, so I imagine it would be
useful to others as well.
I understand that there is the org-collector module, but this isn't
quite sufficient. Although it permits arbitrary lisp expressions, it
doesn't allow one to customize what's printed for the column-headers,
like a normal columnview block would allow.
Regards,
Mark
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Arbitrary lisp functions in column-attributes
2013-10-31 16:41 Mark Edgington
@ 2013-10-31 17:56 ` Aaron Ecay
2013-11-01 19:47 ` Mark Edgington
0 siblings, 1 reply; 11+ messages in thread
From: Aaron Ecay @ 2013-10-31 17:56 UTC (permalink / raw)
To: Mark Edgington, emacs-orgmode
Hi Mark,
This seems like an intriguing idea. I have just one question: how would
this interact with editing in column view? Would function-valued
property columns be read only? Or do you have something different in
mind?
--
Aaron Ecay
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Arbitrary lisp functions in column-attributes
2013-10-31 17:56 ` Aaron Ecay
@ 2013-11-01 19:47 ` Mark Edgington
2013-11-03 22:38 ` Aaron Ecay
0 siblings, 1 reply; 11+ messages in thread
From: Mark Edgington @ 2013-11-01 19:47 UTC (permalink / raw)
To: emacs-orgmode
Hi Aaron,
I hadn't actually foreseen using it for column-view so much, but
rather for a dynamic-block which generates a column-view of a tree.
These are, as far as I understand, read-only.
I don't think it would work well with read-write column-views, so if
such a function were defined in the :COLUMNS: property, it should
either be ignored and not displayed in the R/W column-view, or it
could be displayed if there were some way of ensuring that the
associated column was R/O.
Maybe others have a better idea on how to handle this? I am somewhat
partial to the scheme used in org-collector, where columns are defined
at the beginning of a dynamic block, and not in the original tree.
This way you can have several different dynamic blocks which summarize
the tree-data in different ways. It would also allow the
column-definitions defined in the tree to be used only for the R/W
column-view of that tree.
Regards,
Mark
On Thu, Oct 31, 2013 at 1:56 PM, Aaron Ecay <aaronecay@gmail.com> wrote:
> Hi Mark,
>
> This seems like an intriguing idea. I have just one question: how would
> this interact with editing in column view? Would function-valued
> property columns be read only? Or do you have something different in
> mind?
>
> --
> Aaron Ecay
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Arbitrary lisp functions in column-attributes
2013-11-01 19:47 ` Mark Edgington
@ 2013-11-03 22:38 ` Aaron Ecay
2013-11-04 3:09 ` Mark Edgington
0 siblings, 1 reply; 11+ messages in thread
From: Aaron Ecay @ 2013-11-03 22:38 UTC (permalink / raw)
To: Mark Edgington, emacs-orgmode
Hi Mark,
How about using an elisp babel block, with tabular results? Something
like (tested only very lightly):
#+BEGIN_SRC elisp :results table
(cons
(list "Header A" "Header B")
(cons 'hline
(org-map-entries
(lambda ()
(list
(princ (org-entry-get (point) "FOO"))
(princ (identity (org-entry-get (point) "BAR"))))))))
#+END_SRC
Replace ‘identity’ with your desired lisp-level processing.
--
Aaron Ecay
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Arbitrary lisp functions in column-attributes
2013-11-03 22:38 ` Aaron Ecay
@ 2013-11-04 3:09 ` Mark Edgington
0 siblings, 0 replies; 11+ messages in thread
From: Mark Edgington @ 2013-11-04 3:09 UTC (permalink / raw)
To: Mark Edgington, emacs-orgmode
> How about using an elisp babel block, with tabular results? Something
> like (tested only very lightly):
>
> #+BEGIN_SRC elisp :results table
> (cons
> (list "Header A" "Header B")
> (cons 'hline
> (org-map-entries
> (lambda ()
> (list
> (princ (org-entry-get (point) "FOO"))
> (princ (identity (org-entry-get (point) "BAR"))))))))
> #+END_SRC
>
> Replace ‘identity’ with your desired lisp-level processing.
Hi Aaron,
I think this could be useful for doing some more general processing of
the properties of trees (e.g. using functions of multiple properties),
but it requires more "low-level" programming than just using a COLUMNS
definition. Furthermore, as far as I can tell, you would need to use
something other than org-entry-get to get an entry's headline (e.g.
'ITEM' in the COLUMNS definition). If you used babel to do this, you
would also not be able to (without reinventing them in elisp) use any
of the special summary functions, like when you specify COLUMNS to
include %MYPROP(Col Title){mean}. Also, it requires extra conditional
code to limit the results to the properties of a particular subtree.
With dynamic blocks, I can just specify an ID.
I do like the flexibility that the babel-block method offers, but
maybe this same flexibility could be offered via a different kind of
column-attribute definition -- perhaps a syntax like %FUNC(Col
Title){myfunc,PROP1NAME,PROP2NAME,...} (or simply omit 'FUNC') which
would pass PROP1NAME and PROP2NAME to myfunc. Thoughts?
Regards,
Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-11-06 12:25 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-28 17:00 Arbitrary lisp functions in column-attributes Mark Edgington
2013-11-04 12:08 ` Bastien
2013-11-04 17:56 ` Mark Edgington
2013-11-05 21:06 ` Bastien
2013-11-06 5:02 ` Mark Edgington
2013-11-06 8:20 ` Bastien
-- strict thread matches above, loose matches on Subject: below --
2013-10-31 16:41 Mark Edgington
2013-10-31 17:56 ` Aaron Ecay
2013-11-01 19:47 ` Mark Edgington
2013-11-03 22:38 ` Aaron Ecay
2013-11-04 3:09 ` Mark Edgington
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).