On Mon, May 27, 2013 at 7:42 PM, Terry Brown <[email protected]>wrote:
So, some more specific thoughts, better / other ideas welcome, not sure
> when any coding might occur.
>
> p.v.u['str_tags'] = ['one', 'two words']
>
> This doesn't work, which is reasonable, what I was thinking was JSON
> encoding would be nice, but anything but plain strings are still
> hexlified. So...
>
I agree with Kent's later remarks that json is much preferable to
hexlification. However, a transition to json-centric uA's may not be easy,
and in any case is, logically, a separate topic.
Imo, we could use any representation of tags, even unreadable ones, so long
as tags are persistent. Yes, I know, human-readable *representations* of
tags are preferable. I don't need Kent to point out that fact.
In short, we may want to transition to json-centric uA's first. The
simplest thing that could possibly work would be to support a new
convention, namely that p.v.u['json_whatever'] tells Leo to use a json
encoding. There is the potential for problems if plugins already use the
'json' prefix. We'll deal with that as needed.
> p.v.u['str_tags'] = 'one|two words|St. Petersburg, Russia'
>
> Pipe delimited tags? Or stick with commas and expect people to use
> "St. Petersburg - Russia"?
>
> Tags will be unordered?
>
I agree with later comments that tags should be unordered, and that case
should not count, and maybe even that special characters should not count.
>
> API
> tags are lists, or set, of strings, the p.v.u format should not concern
> the user...
>
> c.tags() # all tags in outline
> g.tags() # all tags in all outlines
>
etc.
This seems clumsy. I propose a tags manager, c.tags, an instance of a new
TagManager class, whose methods are c.tags.all_tags, c.tags.global_tags,
etc.
Initially, p.tags() will be something like
>
> return p.v.u['str_tags'].split('|')
>
I care nothing about this level of implementation detail at present. This
should be a matter of concern only for the TagManager class.
GUI
>
> I still favor something like the bookmarks.py GUI illustrated at the
> beginning of this thread. But Ville's column in the tree idea is
> interesting too, having both would be nice. The tree view raises the
> question of how to abbreviate tags. Perhaps either
> g.app.db['tags']['abbreviation'][tag], or @settings --> @data
> tag_abbreviations.
>
I would prefer to keep gui issues separate from data issues. That way
individual plugins can represent tags as they will.
I agree with Kent et. al. that tag-completion will be important. Support
for tag-completion should be part of the c.tags manager class. It should
be possible to do this in a gui-independent manner.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
