Trying to see the future, I think I'm less interested in 'what tags are on this node?' than 'what nodes have this tag?'
So I would expect to use the list returned by g.tags(['leo tip', 'command']) to build a tree of cloned nodes. As such, I wouldn't be interested in adding tag data to the tree pane, other than a quick 'tagged or not tagged' visual indicator (color?) I would want my nodes tagged. (I never meta data I didn't like) So, I would be happy with a per node tag window. This is getting interesting, feels like a small step -> giant leap thing. "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." Is Leo hexifying? If that's what you mean, let's all jump on Edward, make him change ua's to plain text. JSON has won, pickles lost, get out the white flag. Thanks, Kent 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 > > 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? > > 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 > c.tags_positions_for_tags(list_of_tags) > g.tags_positions_for_tags(list_of_tags) > c.tags_vnodes_for_tags(list_of_tags, unique=True) > g.tags_vnodes_for_tags(list_of_tags, unique=True) > p.tags() # all tags for position > p.tags_add(list_of_tags) > p.tags_remove(list_of_tags) > p.tags_set(list_of_tags) # remove all and replace > p.tags_has_tags(list_of_tags) # check p has all these tags > > Initially, p.tags() will be something like > > return p.v.u['str_tags'].split('|') > > with optimization (caching) for speed when it is needed, not > prematurely. > > 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. > > Also coloring for tags, I think this is good for rapid visual scanning > - perhaps the random-deterministic approach bookmarks.py uses, with > user supplied overrides in g.app.db / @settings as above. > > Clicking a particular tag, perhaps with a modifier, could take you to > the next node with the same tag. Clicking a tag with a different > modifier could remove that tag from the node. Kent's comment that > adding tags to nodes should feature some kind of autocompletion / drop > down list makes sense too. > > Comments? > > -- > 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.
