Hyphens for tags, todo keywords, and properties

Hyphens for tags, todo keywords, and properties

[Samuel Wales]

For some reason I can't get used to underscores[1] and I
want to use hyphens (i.e. "-") for tags, todo keywords, and
properties.

Yeah, I'm a maverick.  :) Or maybe a Luddite.  :) Or both.  :)
I know it isn't usual.  :) Org has borrowed from Lisp in other
areas, but not fully for these.

Hyphens seem to work, but I have not tried them much.

What should I know about in order to achieve this aesthetic with
minimal chance of things not working?  I've come to realize I just
won't stand for underscores, most likely.

I think tags are highest priority for this.

Thanks.

Samuel

[1]  Can't seem to get used to FunnyCase or funnyCase either.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

Re: Hyphens for tags, todo keywords, and properties

[Nick Dokos]

Samuel Wales <samologist@gmail.com> wrote:

> For some reason I can't get used to underscores[1] and I
> want to use hyphens (i.e. "-") for tags, todo keywords, and
> properties.
> 

I suspect that this is going to be difficult, if not impossible.
In particular, tags and properties search uses - as a metacharacter,
so having it appear as part of a tag or property would probably
break things there.

Nick

Re: Hyphens for tags, todo keywords, and properties

[Bernt Hansen]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Samuel Wales <samologist@gmail.com> wrote:
>
>> For some reason I can't get used to underscores[1] and I
>> want to use hyphens (i.e. "-") for tags, todo keywords, and
>> properties.
>> 
>
> I suspect that this is going to be difficult, if not impossible.
> In particular, tags and properties search uses - as a metacharacter,
> so having it appear as part of a tag or property would probably
> break things there.

How is tag filtering where you remove a tag with '-TAG' going to
distinguish between a tag with a - and tag you want to remove?

     (tags-todo "-WAITING-CANCELLED/!NEXT"

is that one tag to remove - WAITING-CANCELLED or is it two (-WAITING and -CANCELLED)?

-Bernt

Re: Hyphens for tags, todo keywords, and properties

[Samuel Wales]

On 2012-02-05, Bernt Hansen <bernt@norang.ca> wrote:
> Nick Dokos <nicholas.dokos@hp.com> writes:
>> I suspect that this is going to be difficult, if not impossible.
>> In particular, tags and properties search uses - as a metacharacter,
>> so having it appear as part of a tag or property would probably
>> break things there.
>
> How is tag filtering where you remove a tag with '-TAG' going to
> distinguish between a tag with a - and tag you want to remove?
>
>      (tags-todo "-WAITING-CANCELLED/!NEXT"
>
> is that one tag to remove - WAITING-CANCELLED or is it two (-WAITING and
> -CANCELLED)?

With \\- in the middle, it should be one.

Re: Hyphens for tags, todo keywords, and properties

[Nick Dokos]

Samuel Wales <samologist@gmail.com> wrote:

> On 2012-02-05, Bernt Hansen <bernt@norang.ca> wrote:
> > Nick Dokos <nicholas.dokos@hp.com> writes:
> >> I suspect that this is going to be difficult, if not impossible.
> >> In particular, tags and properties search uses - as a metacharacter,
> >> so having it appear as part of a tag or property would probably
> >> break things there.
> >
> > How is tag filtering where you remove a tag with '-TAG' going to
> > distinguish between a tag with a - and tag you want to remove?
> >
> >      (tags-todo "-WAITING-CANCELLED/!NEXT"
> >
> > is that one tag to remove - WAITING-CANCELLED or is it two (-WAITING and
> > -CANCELLED)?
> 
> With \\- in the middle, it should be one.
> 

[NB: gut feeling, unsupported by actual evidence.]

The trouble is that org in general does not have an escaping mechanism
(something that causes problems in various places).  I'm willing to bet
that there is no such escaping mechanism i tags/properties searching
e.g. To add an escaping mechanism would require, at the very least, some
(probably substantial) number of regexps to be rewritten in order to
deal with escapes, with all the collateral damage that that would
entail: at this point, that's probably a cure that's worse than the
disease.

It might be that ngz's parser might have an escape mechanism already
built-in (my guess is that it probably does not however) or it might be
possible to graft one in without doing too much violence to it. But I'd
guess that trying to do something like this on the existing code base
would be ... difficult.

Nick