[RFC] Providing Hash tag support in TiddlyWiki's

#1

Folks,

I am working on Essential Editions: Personal Notebook edition - development and feedback and was thinking that many non tiddlywiki users discovering it for the first time, may be familiar with hash tags eg #tagname, So I thought about providing some support, so they can use hashtags to find tiddlers or a place within tiddlers.

This post post is to seek [RFC] Requests for Comment.

My Current design includes;

  • The ability to use any has tag of the format “#tagname” is the text of any field, or as a traditional tiddlywiki tag
  • Provide a Side Bar tab listing all the hash tags in use
    • Click on a hash tag to open/create a tiddler of that name
  • When viewing a “hash tag tiddler” list all tiddlers containing or tagged with that hash tag
    • provide an optional button to show/Hide/create a sidebar tab listing all tiddlers using the hashtag
  • On opening any tiddler search it for known #hashtags
    • Not sure what to do with them once known, highlight would be nice, list them ?

What do you imagine a hash tag to mean?

Have you other ideas we could implement to support hash tags?

Thanks in advance

#2

Hashtags are mainly used on platforms such as Twitter and Instagram, where there is no other way of tagging or categorising content.

Hashtags are mainly used to let other people find your posts regarding a topic.

Most hashtags come and go very quickly, and are used for hyped news or similar. Therefore, there are a huge amount of hashtags, and their use is mostly temporary.

WordPress has categories and tags, and tags are somewhat similar to hashtags. In my mind, categories are static, while you can invent new tags for every post. Here, maybe SEO is the big reason for adding tags.

To sum it up, in a personal TiddlyWiki, I see no use for hashtags. But, as TiddlyWiki can be used in many different ways, I’m sure someone will love the idea.

One way of implementing hashtags would be with links. Like this: [[#MyHashTag]]. The tiddler “#MyHashTag” doesn’t have to exist, and if you click the link, you can still show backlinks to the non-existing tiddler in a footer or header view template.

You can also collect all hashtags by filtering for missing tiddlers and the # character:

<ul>
<$list filter="[all[missing]!has[draft.of]regexp:title[^#]sort[title]]" variable=hashtag>
	<li>
		<$link to=<<hashtag>>/> <$count filter="[all[tiddlers]!is[system]search:text<hashtag>]"/>
		<<list-links filter:"[all[tiddlers]!is[system]search:text<hashtag>]">>
	</li>	
</$list>
</ul>

(Code stolen from you!)

2 Likes
#3

Thanks for you perspective.

Yes. One use of hash tags in tiddlywiki is in your text as well as the code above also does, even without linkification.

Hash tags in tiddlywiki could mirror public ones and perhaps even be used in interactions with the twitter plugin or others.

In a way catering for #tagname in addition to regular tw tags is another name space or organising path.

We could build a method to search for #hash tags in other systems.

#4

You may not be aware that Riz & Telmiger both made tools supporting Twitter style #hashtagery.

Riz’s tool is particularly interesting for users of/posters to Twitter. I have used it a lot.

What you do is enter a Twitter style #hashtag in the Tiddler body and on save a copy of the #hashtag is added to the TW tags for that Tiddler. (see here)

There is on caveat in that TW tags are case sensitive whilst Twitter hashtags are not. So I asked him to ensure all #hashtags would become lowercase when duplicated as TW tags.

Best, TT

1 Like
#5

A thought: It might be interesting with a generalized version of this suggestion where fields (not only tags) can be set in-text, say #tags:a tag#, and rendered as “a tag”. If the field is set several times in the text, the values are added as a list. That would open for a simpler (?) workflow. Imagine writing something like

The #tags:book# #title:Harry Potter and the Philosopher’s Stone# by #author:J.K. Rowling# is featuring many interesting characters; the main characters are #character:Harry Potter#, of course, and his friends #character:Ron Weasley# and #character:Hermione Granger#. This book is amongst my #tags:Favourite books#.

The tiddler will have two lines for these fields in edit mode, the upper is a text field (as usual) and below are the in-text values listed as text. The challenge would be to separate these types of field values. Alternatively, the in-text values are added when the tiddler is saved and listed when it is edited again (and they are effectively resistent against deletion from the fields text boxes)

#6

That is an interesting approach, If I understand your suggestion correctly, but I think it is somewhat separate from the hashtag Idea.

Perhaps share some examples for;

#7

Yeah, it seems more complex but after all, the tags are just a list field

The idea about two lines for these fields was that if the tags are added in-text, they cannot be modified in the field “where they belong” to avoid conflicts, but conceptually they are still field values (and should, perhaps, be listed as such)

An example:

image
image834×413 28.6 KB

  • The in-text fields are rendered as simple text
  • The in-text field values are listed in the fields table but not editable
  • One can add additional values to the fields defined in-text (i.e., character)
#8

I believe this is the best approach, so we don’t need another filter operator for the hash tag.

And I think text field can also be modified by the tag field, when we deleted a tag, we can also delete the hash tag on text field on save.

This logic has to be re-implemented in the WYSIWYG editor because it is auto-saved, there will be no save button.

1 Like
#9

Yes I have revived this Topic as it was started by me and I have finally returned to it.

I have revived the idea but in a simple way and this is as simple title links, where that link title begins with a # and not a ## (reserved for later use) I am simply creating a view template item to list all links[] within the current tiddler body beginning with a # eg [[#tagname]] or [[#tag phrase]] at the bottom. And if viewing such titles in the story missing or otherwise listing all tiddlers or system tiddlers containing that hash tag.

In many ways it is a simple use of a naming standard with titles and allows someone to use titles within tiddlers as a “content tag”, rather than a tag on a tiddler (in the tags field).

  • The advantage being they can be placed near a specific part of content within a tiddler.

Extending

Ideas this method can use;

  • Use ctrl-L then type hash to find existing hash tags
    • Modify this to include missing tiddler titles?
  • Could include standard tags prefixed with a hash as well

Futures?

We could enhance the parser and link widget to detect #tagname in our wiki text but then we would need to disambiguate the use of # for ordered lists, However;

  • We could allow the display of #hashtags to be turned off for printing or viewing, in the body and view templates and visible to the reviewer or author only.
#10

We did remove the CamelCase linking by default because of user demand. Hastags can be a plugin, since different mechanisms exist already.

As you wrote, the main problem is, that hashtags may clash with our existing numbered list wikitext formatting, so we would also need to modify all search functions, to avoid false positives.

#11

That is why at present I am focusing on demanding hash tags be title eg [[#hashtag]] and although this takes a little more to type or insert/format (the ctrl-L in editor helps) it is quite easy to create functions, use links[] and backlinks[] to get a lot of the desirable features of hash tags or content tags.

  • You can also see how if designed well this could support any number of special tag and content tag titles based on tiddler prefixes.
    • They can also be used as regular tags if desired.
  • I have long used ## to indicate need more content in word documents then I can search for these later and continue expanding on the content, checking none remain at the end.
    • Call this writers markup

In this example the [[#hash]] is using the title format to delimit the hash tag but we could use other forms if we were to use the parser such as {# or <# and manage the consequences.

  • Keep in mind # as numbered lists are only leading # with whitespace before permitted, although I think it may be fiddly, remembering to only place them after other content it is common in or at the end of sentences/paragraphs etc… where one wants to place a hashtag. ie hash tags only limit is not at the beginning of a line (ignoring whitespace).
#12

So the request is, to extend the CTRL-L dialogue to show missing tiddlers. So they will show up in the list together with existing tiddlers. This has nothing to do with hash-tags.

IMO that may be a valid feature request at GitHub.

#13

I can definitely see a benefit. I remember when playing with one of the alternate Personal Knowledge Management tools (Roam?, Obsidian?, logseq? I dont’ recall), they used a hashtag in the text to add an equivalent of a TW tag entry. If I recall correctly, it was one way. Adding it in the text added the tag, but removing it from the text did not remove the tag. But I think it was a real-time action. Type #…H…a…s…h…<space-or-punctuation> and the tag list was visibly updated to add Hash. It’s an interesting approach, but I like your idea better.

I think there’s no good way around the [[#tagname]] syntax. Without the wrapper, we’d have to disambiguate not only from the ordered list syntax, but in Markdown mode, from the level 1 header syntax.

One interesting extension, would be to allow @ as well as #, to differentiate tags that are meant to represent people (or groups of people.) I use a number of tools that have that convention, and I don’t think it would add much conceptual or implementation weight to this idea.

I could easily see operators built on this idea:

[tag[Book]hashtag[#Favorite]]

The other side of this, though, is that I’m not sure I would use this much. I know that you are quite interesting in avoiding an over-reliance on tags. Maybe some day I’ll get there too. But as discussed recently, I find little need to address that now, except as related to TOCs. So I would simply add another tag and use [tag[Book]tag[Favorite]].

#14

Without thinking too deeply about it, I’ll note that iA Writer (a Markdown editor/note keeper for Mac) uses hashtags for tagging–when there’s a space after the # it’s a heading and when there’s not, it becomes a tag.

Incidentally, iA Writer also uses [[wikilinks]].

#15

Yes, It would be worth looking to see if there are other cases that exclude missing tiddler titles, even standard search?, perhaps a checkbox option?

  • I wonder if the ability to filter the ctrl-L to only list according to a selectable filter eg prefix[#] or prefix[@] or clone it for multiple filtered lookup. However if you add search tabs they are visible within ctrl-L, this could be the way to introduce access to missing tiddlers but they will not be found amongst the existing titles.

Yes the more recent design approach of just using titles, could be configured to make other prefixes like @person a trivial addition. The thing is we can draw from this that a #tag is a form of tag typically (but not exclusively) within content, if you open the #tag you see details about where used, similarly this would also be the case for @person tags,

The designer would need to choose if the @person tiddler is also a contact tiddler or if some kind of link or redirect to the actual contact tiddler is needed. See further innovation.

I expect this would be wiki or content related such as wikis with too many tags or content needing in place tagging.

  • A de facto standard emerging ?

Further innovation

Given the example of an @person or “at tag” makes me ask could such @person (content tags) actually be an alias to another tiddler such as “Firstname surname”. The @person tiddler may exist but what if it looks for the “Firstname surname” tiddler (perhaps with a field or traditional tag of @person).

  • This idea of tags and or #hashtags or @tags being aliases for other titles is one I would like to explore.
  • Perhaps we have a content-tags field that may contain #tag and/or @tags (list) to indicate that tiddler pertains directly to the named content tags eg [[Firstname surname]] has content-tags="@person"
    • Can we find away on use of an @person content tag to “request” assignment to another person tiddler?
  • Let us not forget using [[Firstname surname]] directly.

If you want to search for a # or @ tag or contact tag (and others a user may use) you have to enter more characters or add two spaces, what if such characters triggered an immediate search rather that wait for the configured minimum of 3 characters to start search?

#16

I have identified the following places we may want to add support for content tags like #tags and @tags.

  • ViewTemplate on tiddlers that ARE content tags, that allow listing of tiddlers containing that content tag
  • ViewTemplate on tiddlers that CONTAIN content tags, that allow listing of tiddlers containing that content tag
  • Sidebar more tab to list all content tags in the wiki, one tab for each content tag
    • Option to show on sidebar tabs for quicker access
  • Advanced search tab that lists each content tag meeting search criteria
  • Advanced Search filter tiddler for searching in Advanced search filter tab

Can you think of any other places we need to provide support for such content tags?

Is it sufficient to package static tiddlers for each content tag that a user installs or would it be worth giving a tool to configure and generate additional content tags (driven by tiddler prefixes)

  • Eg #hashtag @persontag can also be a place/address tag eg @home
#17

Possibly a filter operator that determines if the hash tag is in the text (maybe other field as well) of the input tiddlers:

[some[tiddlers]hashtag[#Friendly]]  or
[some[tiddlers]hashtag:fieldname[@Jeremy]]
1 Like
#18

Scott, Yes now days it is good to use functions and also make them available for use as desired.

Here is a working example but only focused on the text field as I am using links and backlinks.

  • My feeling is if we move into fieldnames as well we may have a separate system for categories, subjects or keywords instead of hash tags which I am defining as “content tags”
\define hashtag-symbol() #
<!-- The prefix symbol we are using, clone and change? -->
\define hashtag-limit-prefix() ##
<!-- eliminate titles with more than one # prefix like '##' leaving such forms for other uses -->
\function hashtag.prefix() [prefix<hashtag-symbol>!prefix<hashtag-limit-prefix>]
<!-- combines hashtag-symbol and hashtag-limit-prefix into the function hashtag.prefix -->
\function all.hashtags() [all[shadows+tiddlers+missing]hashtag.prefix[]sort[]]
<!-- 'all.hashtags' found in wiki and name sorted -->
\function is.hashtag() [hashtag.prefix[]]
<!-- 'is.hashtag' is the current tiddler a hashtag? if not don't return current title-->
\function hashtags.here() [links[]hashtag.prefix[]]
<!-- return the hashtags in the text of the current title -->
\function find.hashtag() [backlinks[]]
<!-- find tiddlers containing the currentTiddler as a hash tag, must start with hashtag.prefix unsorted -->

# hashtag-symbol <<hashtag-symbol>>
# hashtag-limit-prefix <<hashtag-limit-prefix>>
# hashtag.prefix[] {{{  [[#test]hashtag.prefix[]] }}} not {{{  [[@test]hashtag.prefix[]] }}}
# is.hashtag[], title is.hashtag return title {{{  [[#test]is.hashtag[]] }}}
# all.hashtags[] {{{  [all.hashtags[]] }}}
# hashtags.here[] {{{  [all[current]hashtags.here[]] }}}
# find.hashtag[] #test {{{  [[#test]find.hashtag[]] }}} can just use backlinks of the hashtag title
  • minor edit applied to is.hashtag[]

Edit notes

  • If I gave up on the hashtag-limit-prefix we could create a contentTag with the prefix defaulting to # but allow any other prefix to be used. what about textTag, bodyTag, userTag where we may use userTag[] defaults to userTag[#] or userTag[@]
#19

Here is an example of a simpler userTag because we provide a default prefix.

  • This method could permit provision of the fieldname as a second parameter but we would need alternative to links[] and backlinks[] as they default to text.
  • Noting here this would be a quick way to iterate tags eg [links[tags]] and [backlinks[tags]] and other list fields we expect to contain titles (needs further thought).
\function all.userTags(prefix:"#") [all[shadows+tiddlers+missing]prefix<prefix>sort[]]
<!-- 'all.userTags' found in wiki and name sorted -->
\function is.userTag(prefix:"#") [prefix<prefix>]
<!-- 'is.userTag' is the current tiddler a userTag? defaulting to # if not don't return current title-->
\function userTags.here(prefix:"#") [links[]prefix<prefix>]
<!-- return the userTags in the text of the current title -->
\function find.userTag(prefix:"#") [backlinks[]prefix<prefix>]
<!-- find tiddlers containing the currentTiddler as a userTag, must start with prefix unsorted -->

# is.userTag, title is.userTag return title '{{{  [[#test]is.userTag[]] }}}'
# all.userTags {{{  [all.userTags[]] }}}
# userTags.here {{{  [all[current]userTags.here[]] }}}
# find.userTag #test {{{  [[#test]find.userTag[]] }}} can just use backlinks of the userTag title
;Using @
# all.userTags[@] {{{  [all.userTags[@]] }}}
# userTags.here[@] {{{  [all[current]userTags.here[@]] }}}
# find.userTag[@] {{{  [[@contact name]find.userTag[@]] }}} can just use backlinks of the userTag title
  • find.userTag for @contact name currently not working

Note;

Each time I write something for tiddlywiki I often see even simpler and more general ways to implement it.

Generalisation 1

In this case the idea would be to generalise user tags, or content tags to any title links in text by default missing or otherwise beginning with a single character found in a list, this would allow viewTemplates etc… to be designed to handle any one of the titles with these prefixes. And perhaps allowing * for all fields, It would leave it to the user which and how they are used.

Generalisation 2

Dump the single character prefixes and let any named prefix to be used

Parameter to be used to name the fieldname for links[] and backlinks[] ?

@pmario perhaps this is another Github request to allow the parameter to name the fieldname for links[] and backlinks[] in which to search for titles, defaulting to text of course. Along with;

This would modify

This could modify