emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <dominik@science.uva.nl>
To: Dan Davison <davison@stats.ox.ac.uk>
Cc: emacs org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: property searches and numerical values
Date: Wed, 23 Apr 2008 08:54:07 +0200	[thread overview]
Message-ID: <5C89AF80-B5FC-4B4F-B682-3140222B4664@science.uva.nl> (raw)
In-Reply-To: <20080417121958.GA29729@stats.ox.ac.uk>


[-- Attachment #1.1: Type: text/plain, Size: 3914 bytes --]

Hi Dan,

general comparison operators for properties should have been  
implemented a long time ago, thanks for bring this up.  This is now  
available in the GIT repository and will be part of the upcoming 6.02  
release - thanks for raising this point.

Unfortunately there are no good examples for true custom searches  
available.  Some of this is described in the manual.  Basically, you  
need to use a general search to pre-select some entries, for example a  
tags/property search with the criterion "LEVEL>=2" (this already uses  
the new operators, so in order to do this, make sure you have the  
latest devellopment version...).  Then you need to write a function  
that will decide if the entry at point should really be included, and  
if not, where to continue the search.  A short description of this  
with a small example can be found here:

http://orgmode.org/manual/Special-agenda-views.html#Special-agenda-views


HTH

- Carsten

On Apr 17, 2008, at 2:19 PM, Dan Davison wrote:

> I'd like to ask about ways in which (sorted) sparse trees can be  
> produced based on numerical-valued properties. One thing I have in  
> mind is that it would seem natural to treat priority as a (1- 
> dimensional) numerical quantity, rather than as a categorical  
> variable as it seems to be currently. i.e. I'm attracted by the idea  
> of being able to generate a sparse tree containing all subtrees with  
> priority greater than 2.5, and to have headings in the sparse tree  
> sorted by priority. (Of course I'm not suggesting replacing the  
> current priority system; in the above by 'priority' I mean some user  
> defined numerical-valued property.) [ Am I right in thinking that  
> one also can't do this currently with timestamps? Not that that is  
> necessarily needed as the agenda view does a lovely job. ]
>
> So one version of my question would be
>
> q1. Would it be possible to implement binary comparison operators  
> >,<,>=,<= for use in tag and property searches? (If true numeric  
> comparisons are difficult, then alphanumeric would still be useful.)
>
> Sorry if this is available already.
>
> I also have a more general question, which may well arise from my  
> ignorance of what's available. I should admit at the outset that so  
> far I haven't attempted to do anything other than completely basic  
> customisations of org-mode.
>
> q2:  It's my impression that the majority of current users aren't  
> scared of (e)lisp. (personally I am skill/knowledge-less but not  
> scared). Is there a 'template'/'model' function a user should look  
> at if they wanted to implement their own sparse-tree creation  
> function? I am thinking of a function that takes as arguments a  
> node's properties (and possibly also tags, priority, timestamps),  
> and computes a TRUE/FALSE value (err, t/nil?) that specifies whether  
> the subtree rooted at that point should be included in the search  
> results. I've seen the section in the manual 'using the property  
> API'; perhaps what I'm talking about is an extension to that API. If  
> all users had to do were provide a predicate function include- 
> subtree-in-sparse-tree, and org-mode deals with the tree traversal,  
> producing the formatted output, etc, then perhaps it wouldn't be  
> that hard for a user to implement something new like the >  
> operators? Perhaps. Having said all that, of course I do appreciate  
> the nice intuitive syntax for performing tag/property searches. I  
> was just wondering about a general way of making it easy for users  
> to extend the search functionality, and perhaps reduce the burden on  
> the main developer of responding to requests like my q1.
>
> Dan
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode


[-- Attachment #1.2: Type: text/html, Size: 4566 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

      reply	other threads:[~2008-04-23  6:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-17 12:19 property searches and numerical values Dan Davison
2008-04-23  6:54 ` Carsten Dominik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5C89AF80-B5FC-4B4F-B682-3140222B4664@science.uva.nl \
    --to=dominik@science.uva.nl \
    --cc=davison@stats.ox.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).