On Tue, May 28, 2013 at 9:05 AM, Edward K. Ream <[email protected]> wrote:
> 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.
Except for the fact that json has addressed the exceptions and
edge cases which are such a pain to deal with, and solved them
in a way that is widely understood.
>
> 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.
Human-readable is fine, but application-readable is more important.
I think a lot about applications which can consume and produce
data in the form of Leo nodes. Alternatives to json require writing,
testing and maintaining an encode/decode layer.
>
> 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.
>
>
--
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.
