On Tue, 28 May 2013 09:05:07 -0500 "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. > > 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. I wouldn't want to delay the tag code, as long as p.tags() gives the tags for position p, it doesn't matter where it gets them from. Human readable, or rather XML parser searchable, representation would be nice, but not central. > > 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. I think the consensus was that ordering was desirable, at least for the first three tags. Ordering is probably ok as long as tag re-ordering and filtering by tag order are not seen as high priority, i.e. a node can probably remember the order its tags were added, more than that would be very low priority for implementation. I confounded the issues of tag syntax and v.u / xml representation before. So, ignoring v.u / xml representation, should tags be allowed to contain commas - the consensus seems to be no, although perhaps the strongest reason for not allowing them would be the desire to use commas during tag entry, which may not be necessary depending on GUI behavior. More generally there's the question of which characters carry information in a tag. I'm thinking that it should be restricted to characters for which str.isalnum() is True, without regard to case. So all of the following would be equivalent: St. Petersburg - Russia st-petersburg-russia #St_Petersburg-Russia stpetersburgrussia Internally they'd all be hashed as the last form, but for presentation they'd try and use the form originally entered. > > 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. Yes, that would be better namespace management. > 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. QCompleter style interaction seems like the most unsurprising first solution - which raises the question of whether Leo needs a generic and simple to re-use LeoQCompleter interface (to enable Ctrl-G etc. etc.). This is probably related to https://bugs.launchpad.net/leo-editor/+bug/1141122 It would be nice if plugins could easily use a Leonine QCompleter without needing to interact with the arcana of Leo's key handling. Cheers -Terry -- 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.
