Hi Mark,
Mark Edgington 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
Hi Bastien,
On Tue, Nov 5, 2013 at 4:06 PM, Bastien 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 mutua
Hi Mark,
Mark Edgington 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 pr
Bastien 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?
Hi Mark,
Mark Edgington 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
> 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
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
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 :CO
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
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 l
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
11 matches
Mail list logo
