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.
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).
Ideas this method can use;
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 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.
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.
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.
# 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).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.
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]].
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]].
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?
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.
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).
[[Firstname surname]] has content-tags="@person"
[[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?
I have identified the following places we may want to add support for content tags like #tags and @tags.
#hashtag @persontag can also be a place/address tag eg @home
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]]
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.
\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
Edit notes
# but allow any other prefix to be used. what about textTag, bodyTag, userTag where we may use userTag[] defaults to userTag[#] or userTag[@]Here is an example of a simpler userTag because we provide a default prefix.
[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
@contact name currently not workingEach time I write something for tiddlywiki I often see even simpler and more general ways to implement it.
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.
Dump the single character prefixes and let any named prefix to be used
@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
One of my issues with this proposal is that it would greatly privilege tags as a data structure. Tags currently have special tools (e.g. a bespoke filter operator, built-in tag manager) to work with them, but for the most part, tags are just another field. Tags would get a meaning within field values, elevating them to the level of wikilinks – which are a more fundamental structure than tags are.
So I think it would muddle things if hashtags were in the core, but I can see this being a popular plugin.
For my part, I would prefer and actually use an interactive mode proposal like this:
Do you mean like a form of autocomplete, as you type?
The feature to add [[#tags]] entered in the text to become titles, is not unlike what is available through the tags pill. Although I personally would like a form of tag that does not fill the tags field on tiddlers, but can mostly be used in similar ways, like testing if they are in the text, listing them including for selection, and listing the tiddlers they tag.
reimagin tags which extends the tag drop down a lot, So I thought of extending hashtags further, but there is something simple and deterministic about the current title driven process.I don’t think we should be concerned with more options and features for “marking” or organising tiddlers. We will just use what we need when we need it. As I am writing a book this idea of hashtags or content tags appeals because it can be used to mark my content, in tiddler, its more specific.
We do start with plugins, but if it was ever in the core it could require a config item be set, to appear or even just using [[#tagsname]] and it becomes visible.
Yes, I actually use Ctrl+l a lot (though bound to Ctrl+k to match other software). I find it indispensable.
I have used CodeMirror 6 as well though mostly for testing purposes and provided feedback to BTC.
It’s not the auto-completion that matters so much as the convenience of adding a tag without breaking out of a writing flow.
I think Scott and I were describing a workflow along the lines of:
#hashtag is appended to the tags field#hashtag is deleted from the text input. My cursor stays where it was.text input is replaced with <<tag #hashtag>>.That’s the point. tags are already “special” in every way. Technically they are not a tiddler field. JS internally, they are an array. The same is true for the list field.
If tags are listed, they use the list-field of a tag-tiddler to provide a custom sort order. There is no other field, that can do that.
Every other field that contains a Title list internally is a string, with special formatting to allow abc [[title with spaces]]. So internally there is a fundamental difference, between tags, list and any other field.
For every tag in the system, the core manages indexes. So if we want to know, which tiddlers are tagged eg: HelloThere, the access is very fast, since the index knows that tiddler list already.
Let’s assume we have 3 tiddlers a, b and c, which contain different “tag-like” titles in my-field
title: a
my-field: a [[a a]]
+
title: b
my-field: b
+
title: c
my-field: a
A) The filter to list tiddlers that contain “a” in my-field would need to look as follows.
\function tag.like(field, tagLike)
[has<field>!is[draft]] :filter[get<field>enlist-input[]match<tagLike>] +[join[, ]]
\end
Tiddlers that contain: `a` -> <<tag.like "my-field" "a">>
test-tag-like-filter.json (877 Bytes)
B) A similar function to get the [tag[HelloThere]] would look like this:
\function f.tag(tag) [tag<tag>!is[draft]] +[join[, ]]
tag contains HelloThere -> <<f.tag HelloThere>>
In example A) we need to
has<field>
!is[draft]
:filter[...]
get<field>,
enlist-input[]
match<tagLike>
+[join[, ]]
Example B)
tag<tag>
!is[draft]
+[join[, ]]
I think it is clear that there is a huge performance benefit. …
So to make “tag-like” titles fast, if they are in fields, we would need a more generalised indexing system.
field:my-field[] operator in a way, that is works like a tag.field:my-field:tag-like<tagLike>
Disadvantage: Every tag-like field would need quite some memory, to store the index.
That’s a completely different part of the core code. links[] and backlinks[] are also very expensive.
IMO these two functionalities have room for improvement.
[[#tag]] this mechanisms are automatically active.Those 2 trie-indexes could probably be used to create a more generic mechanism that could also be used for very performant tag-like field link and backlink handling.
It would probably also be able to handle the existing tag indexes.
I am not sure if it could replace the existing links and backlinks indexes. A lot of experimenting would be needed.
Just some thoughts.
Mario
I just stumbled upon the listed-operator, which uses a global-cache. So it is cached … But – The main problem here is that the global cache is destroyed with every UI interaction.
I’ll update my post accordingly soon. Need to dig a bit deeper.
all,
Please take note I reopened this thread to implement hashtags which I could also call content tags as they are placed within the text field. My proposal is to simply use titles as links [[#tagname]] and make use of existing mechanisms. I have demonstrated a number of custom functions to make handling the # and other title prefixes easier to use.
This is quite simple yet functional and does not involve turning them into regular or alternative field tags. yet it’s quite easy to locate tiddlers containing them, if the current tiddler has one or more, or test if it contains a particular one. you can open any content tag and see where it is mentioned.
So I would appreciate some feedback on this approach specificaly before going too far in another direction and if you are give a reason by comparing with what I proposed.
post script
there is no real need to turn my proposed content tags into regular tags, I am not sure what that would add, just reduce their specificity.
I think this was the primary motivation behind @pmario’s musings (and I’d have the same concerns)…
This may be of less concern if the wiki(s) where you’re using your links/backlinks-based approach aren’t particularly large or text-heavy, of course.
: