[TW5] Another way to make multiple tag-like fields

[Jed Carty]

I know that there have been other implementations of this, but I think most of them use javascript. I have been gone for a while so if I missed someone already doing this I am sorry.

Using the new(ish) listops widget and the existing tags macros I made some things that let you use any field like the tags field. 

I also added some configuration (a tab in the conrol panel) and a view template so that you can have the contents of the other tag-like fields listed in the view template like tags are.

I haven't added the interface to the editing mode yet, so the fields are listed a normal fields.

If you make a field foo and use it as a tag-like field and click on a tag pill bar from the field foo the drop down menu shows all the tidders with  bar in their foo field the same way as if you were using the tag field. This is separate from the tag field so if you have a tag bar and bar in the field foo they won't be connected.

There aren't the tags and tagging operators, to get the equavilent of the tags[] operator for the field foo use list[!!foo], to get the equavilent to the tagging operator using the foo field and the bar tag use [bar]listed[foo]

I am still not at home so have a dropbox link instead of a normal url. When I get home later I will pack it as a plugin and probably add some more options.

https://dl.dropboxusercontent.com/s/2j4326k9mispk41/GenericFieldsAsTags.html?dl=0

[Jed Carty]

I made some improvements. Now you can edit the alternate fields the same way as the tags field. The drop downs listing existing items don't work correctly yet and all of the inputs for a single tiddler use the same temporary tiddler. Type in the text box to add a tag and you will see what I mean.
Other than that it functions correctly. I haven't packaged it as a plugin yet but there are only a few tiddlers if you want to take the code and play with it. I will hopefully get the code on github and package it all as a plugin soon.

I am not sure if this should go in the core or not. It is useful but while it is very similar to how the normal tags field is handled there are some changes that would either require some small bits of duplicate code or some small changes to the existing tags code. It shouldn't hurt much in the way of backwards compatibility but tags are such an important part of tiddlywiki I am not sure how much I trust it.

Also the list operator doesn't act on the input values the way I expected, so [all[]list[!!foo]] only lists what is in the field foo of the current tiddler, this means that I don't have a clean way to list all items in the other fields.

Any ideas, suggestions or questions?

[David Gifford]

Hi Jed

Oh, had I only had this before I started my big Gospels project http://giffmex.org/gospels.bubbles.html

I haven't played with it, but I have it bookmarked and it looks like a really great tweak of TiddlyWiki. There are many times when I would like to have multiple categories of tags.

Dave

[Mat]

Did the Jedi master just solve one of the BIG ones in a really elegant way!??

Must investigate this thoroughly.

@Jed - after a very quick glance I'm wondering about;

• A name for the tag-like things ("semantic tags", "s-tags", "JedTags"... ;-)
  
• Search for the tag-like things.
  
• Option to hide the resulting field from view (This is a big wish.)
  
• Would this solution make it possible to totally replace the normal tags field with this? I mean to make the normal tags field be a special case of the general whatever-we-call-'em-fields? So that managing and manipulating tags fields and tags are done in the same way for every instance.

Very exciting!

For anyone interested in the subject, here are some references to earlier discussions, solutions etc:

• Tobias' lookup-fields (or relationship-fields) #1324
• Allow for the tag and tagging filter to specify a different field#1989
  
• A problem description with a "reversed take" on field name/value (by me) and a solution by Tobias.
• Thoughts on the concept of Tags and Tagging
• Older thread with input from Jeremy
• Tobias write-up of a Stephan Hraded approach for searching fields
• Search By Keywords Tab - another write-up from Tobias, 

<:-)

[Jed Carty]

I can't take too much credit here since the big enabling thing for this is the action-listops widget. If that didn't work as nicely as it does than I would have had much more trouble.

Mat,

They should have some name to show they are a more general thing but I have no idea what to call them. JedTags isn't very easy to say...

A search shouldn't be hard to implement but since [list[!!foo]] ignores the input it may require something less elegant than I would like.

I can hide the fields in view mode, hiding them in edit mode is possible but will require some more work. At the moment I haven't modified anything in the core but I don't think I can go much farther without that.

I have been looking at what would be required to make this be how all tails (tags-in-limbo) are handled. I think that this is one step toward making all the fields in a tiddler polymorphic, which I think would be an important improvement for future versions. So far the biggest thing lacking for just using this instead of the existing tags field is there I don't know how to get the equivalent of the tagging operator for non-tag fields. I think that this was figured out using the action-listops widget so I will look at that.
Backwards compatibility is the only problem with implementing this in the core in place of how tags are done now. I am not certain I can change the tags field portion of the code to be completely consistent with the new method without breaking some existing projects. It should be minor, but tags are important so I need to look closely at the code before I can consider a pull request to the core. Adding this along side the existing tags field implementation would be possible, but would require some duplicate code in the core which I would like to avoid.

So, if you want to use this instead of tags for all of your future projects, there should be no huge problems, it is just not currently polished. The core will require some more thought though.

[Jed Carty]

I made a lot of updates. There aren't many changes in functionality but there should be some huge improvements in usability. You can set which fields you want to use as alternate tag fields globally and you can set a different default color for the tag pills in each field. There is a list in the default tiddler that describes what works and what I am still planning on doing. There will probably be other things added to the plan section and requests are welcome. If I missed something that was already requested let me know.

As a nice side effect, if you use this and put <<EditTagLikeList tags Tags>> in a tiddler it will give you a tag editor in view mode. I remember someone requested that before.

The demo is now here. It isn't a plugin yet because I want to do some more polishing before I release that. I suggest that you wait until I package it as a plugin before using it for anything too important.

[Jed Carty]

Now the custom tag colors should work the same as with normal tags. There is also now a setting that lets you use icons or images, or just any wikified text, as the tag or as the label displayed for the field. The second part doesn't work in the normal tags field, only in the new ones and it must be turned on for each field individually in the settings.

The demo is still here.

[Mat]

I have a feeling (...actually, I know) this will become extremely useful!

Some points;

You talk about (and have implemented - yay!) global such fields but the more fields one have the more likely it is that one will want local control, I think. 

In my very recently released VarsFields thing I included an (optional) editview template that hides the duplicate at bottom that also appear above the text area. I can think of ways to solve it without an overwrite though; the tricky bit is to target the correct list element in the listing of thefields. But the special fields can be named with some never-seen prefix that puts them first or last in the list. The one hides as many list items as there are special fields. When the name of the field(s) is typed otu, the prefix is removed behind the scenes. Reversed for when the field is created.

For tag icons, Matabele is the guru. (...hm... how about pure icon based fields, including the label? Any practical value? I have no idea.)

(For later: Might the idea to use tagpills as tiddlerbundles somehow be intergated here? So one can drag'n drop multiple tiddlers at once using the tag as handle?)

BTW, maybe any of these posts by wizard Tobias is of value for something. They seem related in that they're about managing extra fields, I figure:

* Search by Keywords tab

* Filter operator for "list contains an item or any / all items of another list" #1216

<:-)

[Jed Carty]

The macros TagLikeList and EditTagLikeList are the view and edit parts of what I made. If you just put <<TagLikeList foo Foo>> it will display the contents of the foo field in the current tiddler like it was tags with the label Foo. <<EditTagLikeList foo Foo>> will do the same thing but it is the editing part. They are exactly what is used for the global portions so they should act the same way.

<<TagLikeList foo Foo "" True>> will wikifi the items in the list so you can use icons or images or whatever you want. I may add an optional argument for the display template to use if you want something other than the default tag pill.

I need to work on my tiddler tools generic search so it can work with these other fields. But it probably requires a lot of work anyway. The action-listops widget should simplify a lot of what it does.
I think that the contains operator is going to be very useful but it is a bit specific for what I need now. I can get a list of tiddlers that have the tag foo in field bar using [[foo]listed[bar]], what I need is the equalvilent of [all[]tags[]]. [all[]listed[!!bar]] only gives the results from the current tiddler and ignores the all[] part. Once I get a solution to that than I can make using the alternate fields identical to using the tags field. After I have that I am going to worry about updating tiddler tools to use them for advanced searching.

[Matabele]

Hi Jed

It should be possible to modify the existing filters designed for the tags field, so as to handle any field containing a list. The hurdle will be maintaining backward compatibility.

A syntax something like tag:field[mytag] and tagging:field[] might be acceptable (with default field = 'tags'.) When I looked at it, some of the other cases were more difficult as far as I recall.

regards

P.S. In the meantime, as an alternative to the listed[] filter, the regexp[] filter provides a useful way to search a field for an item.

[Mat]

I was evidently unclear with my points; but actually, never mind. I'll clarify at a later point, theyre not important now.

using [[foo]listed[bar]], what I need is the equalvilent of [all[]tags[]]. [all[]listed[!!bar]] only gives the results from the current tiddler and ignores the all[] part.

maybe

[all[]get[demo]]

...?

<:-)
 

[Mat]

I meant "bar". Who the hell wants a "demo" when you can get a whole bar.

<:-)

[Jed Carty]

Matabele,

Using the existing names like that may be the way to go but there are things specific to how the tags field is handled behind the scenes that would prevent just pointing the same code at a different field from working. Tags are stored in comma separated lists and there is some processing done whenever you look at or change the the text of the field to switch between the forms.

I would like to change the listed[] operator to act on the list of input titles instead of only a single title since it is a more general solution but I am not sure what that would break.

And for using rexexp[], the problem isn't searching. I need a list of every unique item listed in the demo field of all tiddlers so I can build a list of them.

Mat,

I think that the set widget hates me. I adds [[ and ]] around each thing returned by a filter if there are spaces. Title lists are space separated so you get results like
[[one two [[three and four]]]] [[bob joe two]] [[eddie one]]
from using [all[]get[bar]] and it is very frustrating.

[Mat]

I think that the set widget hates me. I adds [[ and ]] around each thing returned by a filter if there are spaces. Title lists are space separated so you get results like
[[one two [[three and four]]]] [[bob joe two]] [[eddie one]]
from using [all[]get[bar]] and it is very frustrating.

I have spent hours and hours just testing filters so I can tell you the set widget doesn't hate you personally. I get the double brackets too. Try with a listwidget instead. 

FYI, I have called attention to the difficulty with this in #2363 (please do comment there). I also have a case where I don't know what to do about this. BTW, check out the following interesting example with identical filters:

mylist: aa [[bb bb]] cc
text:
<$set name="item" filter="[<currentTiddler>get[mylist]]" >
<<item>>
</$set>
<br>
<$list variable="item" filter="[<currentTiddler>get[mylist]]" >
<<item>>
</$list>

...pretty interesting, eh?

<:-)

[c pa]

Jed,

I created a get all values in a list filter here:

http://cpashow.tiddlyspot.com/#%24%3A%2F_cpa%2Fmodules%2Ffilters%2Fgetfieldlist.js

[Jed Carty]

I gave in and just edited the tags filter, it turns out it took much less than I expected. So you can use [tags:foo[]] to get the list of things in the foo field instead of in the tags field.

So, with this the other fields can be used the same way as tags field. I am not sure if there is an equivalent to [tag[bar]] at the moment, but I am planning on editing the tag[] operator to work the same way as the tags operator so that should be fixed later.

When you are in edit mode now you get a drop down showing a list of existing tags for that field and it works the same as for the tags field so you just need to click on the tag to add it.

Not everything is perfect but it is in a state that can be used without much worry.

[Mat]

On Monday, May 23, 2016 at 11:29:25 PM UTC+2, Jed Carty wrote:

I gave in and just edited the tags filter, it turns out it took much less than I expected. So you can use [tags:foo[]] to get the list of things in the foo field instead of in the tags field.

Good working! At this stage I think there is no problem because, as I see it, this stage is mostly about defining the concept and making sure people can try it.

Besides, with arbitrary field names one must probably... Actually, let me say this first:

For field creation, there must be a safety check. I just tested to create a field named "text" and it worked "too well". It should be simple to block overwrite of the standard field names (there exists such a check when you try to create a field named "text" in a standard tiddler) and is should be simple to block globally defined GenTags fields, but what if I have "mytiddlerlocalfield" in MyTiddler...?

Now, back to what I was about to say; such a safety check is probably (!) also necessary to ensure that fields are not titled same as filter operators! ...but the fact that we don't have this check for regular fields makes me unsure (cos we don't, right?). At the moment I fail to concoct a good example of how this could be a problem but considering how a filter consists of both operators and field names... surely this is a risk, right? Assuming it is, then a tool like GenTags will increase the risk tremendously.

<:-)

[Jed Carty]

It would be simple enough to create a list of disallowed field names like text, tags, title, modified, created, author and whatever other names we need. I can just make it hide the add button when you enter one of those names with a note that they are restricted fields. I am not sure if tags needs to be on the list or not. I will probably put it on to prevent confusion.

And for filter operators, if I understand correctly I don't think that you could cause problems by naming fields the same as filter operators. In order to be a problem you would need a field with [ in the title, something like a field called foo[ would make the filter [tags:foo[[]] and break things, but [ isn't one of the allowed characters so that should problem is already covered.

[Jed Carty]

This is now cleaned up a bit and packaged as a plugin. It should be easier to set up and use the fields now. I still need to make documentation though. The plugin is available in the same place here.

[Jed Carty]

This now has a readme in the plugin and the macro tiddler has documentation for the macros. There is also a much shorter and easier to understand demo. Everything is still here.

You should be able to use this as an alternative to the normal tags field in every way except I don't have an exact alternative for !tag[foo] for the other fields. You can do the equivalent of tag[foo] by [foo]listed[fieldname] so it is only the negation part that is missing.

[Jed Carty]

If you want to see the plugin in action I am adding topics as a secondary tag field on the wiki reference wiki.

This made me realize that someone should update the toc macros so they can be set to use a field other than just tags.

[Mat]

Jed, I note that clicking a GenTag that appears in multiple fields (e.g the zzz in the demo) opens the dropdown for all those instances (except for when in the main tags field).

<:-)

[Mat]

Further, in the dropdown list it seems there is a difference for the top-most element (i.e the possible link to the tag itself) if the field wikifies or not. I'm thinking the dropdown list should probably behave like regular tags, i.e it should be a link.

<:-)

[cmari]

Oddly, it seems it is not possible to add field values using the dropdown menu in Chrome. Clicking a "tag" pill on the dropdown "tag name" list causes navigation away to the "tag" (whether it exists as a tiddler or not), rather than populating the field. Things work as expected in Firefox.
cmari

[cmari]

Any ideas why this doesn't work in Chrome? (I tested this by opening http://inmysocks.tiddlyspot.com in the most current version of Chrome on Windows. Create a new tiddler. Click the down arrow next to "Topics" and click on a tag pill. Every time I try this, the cursor moves to the "tag" I just clicked and no topic is added.)
cmari

[Jed Carty]

I changed a bit of the macro that had used the link catcher for the normal tags field. It looks like that may be needed in chrome. I am working on twederation things now but when I get that finished I will hopefully take a look at it.

[RichardWilliamSmith]

Confirmed broken on Chrome for Mac, Version 51.0.2704.79 (64-bit) 

RR

[Jeff Vance]

Hi Jed,

Thanks a lot for making this plugin.  I was trying to find a way to organize my notes a certain way and this solves it for me perfectly.  

I did find a small bug:

- When creating new fields for tags in the control panel, if you accidentally enter an invalid name for the field (like inserting a space), it creates a tiddler (that apparently goes unused) of the form [[$:/settings/AlternateTagFields/bad field]].  This shows up in the recent tab.  I just deleted it, so no worries.

[Danielo Rodríguez]

El lunes, 23 de mayo de 2016, 0:56:17 (UTC+2), Jed Carty escribió:

I made some improvements. Now you can edit the alternate fields the same way as the tags field.

How? 

[Jed Carty]

The demo here http://ooktech.com/jed/ExampleWikis/GenericTagFields/ has the information, you can add fields using the control panel and they are listed in the edit template like the tags field

[Danielo Rodríguez]

El viernes, 2 de septiembre de 2016, 10:45:56 (UTC+2), Jed Carty escribió:

The demo here http://ooktech.com/jed/ExampleWikis/GenericTagFields/ has the information, you can add fields using the control panel and they are listed in the edit template like the tags field

That's a different URL!

Thank you Jed 

[Jon]

Hi,

I've just found Jed's alternative tags plug-in and finding it very useful.

I want to hide the new tags associated with various tiddlers (which you can do via the Control Panel), but would like to see those tag pills in the body of a new tiddler, in the same way that e.g. <<tag A>> would show a tag pill of a regular tag called A. Is this possible with the new tags? 

Perhaps this is possible anyway, to show a field as a tag pill...?

Thanks

Jon

On Sunday, 22 May 2016 18:56:16 UTC+1, Jed Carty wrote:

I know that there have been other implementations of this, but I think most of them use javascript. I have been gone for a while so if I missed someone already doing this I am sorry.

Using the new(ish) listops widget and the existing tags macros I made some things that let you use any field like the tags field. 

I also added some configuration (a tab in the conrol panel) and a view template so that you can have the contents of the other tag-like fields listed in the view template like tags are.

I haven't added the interface to the editing mode yet, so the fields are listed a normal fields.

If you make a field foo and use it as a tag-like field and click on a tag pill bar from the field foo the drop down menu shows all the tidders with  bar in their foo field the same way as if you were using the tag field. This is separate from the tag field so if you have a tag bar and bar in the field foo they won't be connected.

There aren't the tags and tagging operators, to get the equavilent of the tags[] operator for the field foo use list[!!foo], to get the equavilent to the tagging operator using the foo field and the bar tag use [bar]listed[foo]

I am still not at home so have a dropbox link instead of a normal url. When I get home later I will pack it as a plugin and probably add some more options.

https://dl.dropboxusercontent.com/s/2j4326k9mispk41/GenericFieldsAsTags.html?dl=0

[Jed Carty]

Oh, I don't think I added anything that will do that. I have been swamped with work so it will probably be a while before I can get around to updating anything.

[PMario]

On Tuesday, November 22, 2016 at 7:41:53 AM UTC+1, Jon wrote:

Perhaps this is possible anyway, to show a field as a tag pill...?

try: <span class="tc-tag-label">{{!!yourFieldName}}</span>

-m

[Jon]

Jed - thanks, no problem.

Mario, that seems to create a single (v. long) tag pill containing all the tag names...

Thanks

Jon

[PMario]

On Tuesday, November 22, 2016 at 7:02:51 PM UTC+1, Jon wrote:

Mario, that seems to create a single (v. long) tag pill containing all the tag names...

different possibility. ... but there is no forground color change and no other additional functionality. So you'd have to have a look at the tag handling to get more.

<$list filter={{!!mylist}}><span class="tc-tag-label"><<currentTiddler>></span> </$list>

-m

[Jon]

Hi Mario,

That produces the tags in the body of the tiddler OK, but as I think you've anticipated, they don't work, i.e they don't produce a list of items when clicked. "Tag handling" is probably beyond me! Maybe one for Jed when he gets back.

Thanks

Jon

[Riz]

Are you looking for:
<$list filter={{!!myfield}}>{{||$:/core/ui/TagTemplate}}</$list>

[Jon]

Hi Riz,

That's closer - the right colour for the tag pills and there is a drop down to show the name of the tiddler (as the tag) but it doesn't show the tiddlers with the tag.

Thanks

Jon

[Jed Carty]

The problem with what Riz posted is that it isn't the tags field so the list isn't going to show up correctly. Also if you change the colour of the tags in a non-tags field it won't show the correct colour there either. This is an awkward work around for now if you need one:

<$set name=TheField value=field_name>
<$tiddler tiddler=TagName>
{{||$:/plugins/inmysocks/GenericTagFields/LikeTagPills}}
</$tiddler>
</$set>

you have to change field_name to the name of the field your tag is in and the TagName to the tag you want to display. If you just want to display all the tags in a field just use the TagLikeList macro, it is in the tiddler $:/plugins/inmysocks/GenericTagFields/ListLikeTagsMacro in the plugin.

[Diego Mesa]

Hey all

Just became aware of this excellent plugin. Just wanted to mention a few issues and see if anyone else has encountered them or has a potential fix:

1. In the genTags tag dropdown that appears as a result of clicking on the edit box, only the tag itself is highlighted, not the entire row, as is the default for "real" tags.

2. Selecting a new tag from this dropdown does not actually cause the tag to be placed in edit box - instead, it tries to open that tiddler. This means that the tag dropdown selection is not actually working, and the only way to add is to type one in manually

Thanks!

Diego

[Diego Mesa]

Also:

3. The behavior of the tag dropdown in view mode is different across different tag fields:

• Go to: http://ooktech.com/jed/ExampleWikis/GenericTagFields/
• Click on "this tag is in every field" in 
• the core tag field: Note the dropdown "this tag is in every field" is italicized, for a non-existing tiddler, but its the only dropdown that pops up. 
• the demo tag field: Note its and the bullseye dropdown both popup, but the core tag dropdown does not popup. 
• the bullseye tag field: Note it and the demo dropdown both popup (the core tag dropdown also does not popup), but "this tag is in every field" is not italicized, and you can not click it - clicking it causes both dropdowns to close.
• Clicking on any tag in the bullseye tag field shows the tag name in the drop-down to far to the left, and is unclickable. 
• This is a result of the "wikify tags" option being selected - with this off, its behavior matches that of the demo field.

[Jed Carty]

Diego,

I have been busy with other work for a while so I don't know if I will be able to update this anytime soon.

I made the drop-downs for the other tag fields based on tag instead of on tag and on field. At some point I will probably change it to use both so there aren't multiple dropdowns when you have the same tag in multiple fields. When using it I haven't ever had the same tag in multiple fields in the same tiddler so it wasn't a priority for me.

For the part about selecting from the dropdown to add the tag to the current field, I am not sure that I ever looked at adding that. It should just be adding a link catcher widget so I will see if I can add it at some point.

And yes, the dropdown acts differently when you wikify the tags. This is because the wikify widget is used which prevents the other behaviour. I am not sure if there is a way around this, but if I didn't have the wikify widget there than instead of showing the tag field name wikified like it is everywhere else it would show something like {{$:/core/images/close-others}} instead of the bullseye. I liked the current behaviour better. If I have time at some point in the future I will try and track down all the edge cases, but I doubt that will be any time soon.

[Diego Mesa]

Completely understand Jed! Just figured I should note them down somewhere (kind of like github issues). 

For me, the only real impediment is being able to click a tag from the dropdown and having it actually become a tag, instead of it trying to open the tiddler. In the meantime, I will try to take a look at it myself and report back.

Best,

Diego

[coda coder]

Wow, Jed.

1 - When it has the same general UX as regular tags, it should be in the core, IMO.

2 - Kudos.  Even if just for seeing an immediate problem (use-case) solved by ListOps widget, great stuff.

3 - Hell, call it JediTags - sounds fine to me.

On Monday, December 4, 2017 at 4:45:32 AM UTC-6, Jed Carty wrote: