Thanks for sharing!
-m
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywiki+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@goo
Thanks for the post,
While a bit blown out of proportion, discussion-wise, here's a
related issue:
https://github.com/Jermolene/TiddlyWiki5/issues/1324
Best wishes, Tobias.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from th
@Tobias Beer & @PMario Thanks for the comments guys, you're welcome. :)
@Tobias Beer what you describe in that link is a very well worded
description of the limitations I found with the current set of tools, and
exactly what I envision would be a perfect solution. I sure as hell would
love to s
Here's how I would envision some "multiple-tag-fields" components to work
off the top off my head...
1) the user defines fields that function as *tagsets*, like all fields in
lowercase, which when used are entered and interpreted as if standard tags,
but not returned by standard tag filters, e.
Hey I just figured out this can effectively used to have a separate
hierarchy of "Categories" and "Tags", where categories can be used for the
table of contents sidebar macro, and the tags can be used as regular tags
without disrupting the tree view. One can use a prefix like "Toc/###" or
"Cate
Hi, i'm trying to understand the purpose of this but my mind refuse lol: is
there a place where we can see this in action or could you provide a
screenshot please ?
I have tried to copy what you have published above but without success..
Thank you
Ps: congratulations too for the poster, looks n
Hello Spangenhelm, the method explained here is a way to virtually have
multiple tag fields on the same tiddler.
It simulates the option of having two or more distinct fields in the same
tiddler that behave in the same way that the default tag editor does, with
the benefits it brings, like the a
Using prefixes looks a bit redundant.
I would rather give every platform-type a tag *platform* and then construct
the filter based off of that, e.g
[tag[platform]tagging[]]
[tag[output-format]tagging[]]
...and then only use mac, linux windows ...or the corresponding mime types
as titles.
You are right Tobias, nice one! That would indeed be easier in this case.
I guess I just did it blindly for consistency/continuity, since the formats
used the prefix method because of the distinction between Input and Output
I'll probably rework those since it's still WIP, there is still no separ
>
> I guess I just did it blindly for consistency/continuity, since the
> formats used the prefix method because of the distinction between Input and
> Output
>
...which really begs for using dedicated fields, though, imho.
Best wishes,
— tb
--
You received this message because you are sub
For the formats input and output tags it won't work, because for example a
tiddler named JPEG could belong to input or output or both on the same
tiddler.
On second though using tags for platforms has undesirable effects, like
adding a new platform will not show immediately, since you have to m
I have created a widget called field-mangler-ext that allows you to select
to which field add the tags.
It is not perfect, but it works. It's part of a plugin I am working at.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from th
Hey Danielo that sounds very interesting, looking forward to that plugin
On Friday, 2 October 2015 21:52:54 UTC+1, Danielo Rodríguez wrote:
>
> I have created a widget called field-mangler-ext that allows you to select
> to which field add the tags.
> It is not perfect, but it works. It's part o
This is one of the things I have been poking a bit recently. I have an
early version of some modifications that allow multiple tag fields. There
are formatting problems but most of the basic parts work.
Currently these work:
tm-add-tag
tm-remove-tag
tag filter operator
tags filter operator
I ch
Hey Jed,
Seems like we have been working on the same stuff.
Here is my code, let me know if yours is different:
https://gist.github.com/danielo515/bcdc4b79e9f82f29ecb4
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this gro
Hi Danielo and Jed,
I'm wondering why you two chose to touch the fieldmangler for that.
Best wishes,
— tb
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddl
Tobias,
Because it was the most straight forward way to extend the tags directly.
It turns out that it isn't as efficient, but it has the most you can reuse.
Danielo,
I changed to using action widgets. It turns out it is a much easier way to
go and should be better for future updates.
The disc
This is a great tool Jed! It will work great for my project management TW.
On Sunday, October 4, 2015 at 3:32:24 PM UTC-4, Jed Carty wrote:
>
> Tobias,
> Because it was the most straight forward way to extend the tags directly.
> It turns out that it isn't as efficient, but it has the most y
El domingo, 4 de octubre de 2015, 17:56:44 (UTC+2), Tobias Beer escribió:
>
> Hi Danielo and Jed,
>
> I'm wondering why you two chose to touch the fieldmangler for that.
>
> Best wishes,
>
> — tb
>
I have not touched the fieldmangler in any way. Field mangler widget
remains untouched, I just ext
I just made a new action widget. It will probably be put into the
action-setfield widget if it does make it to the core but this allows
things to be much more modular since this is a single file that adds a
single widget.
What I have is here
http://ooktech.com/jed/ExampleWikis/ListManipulation
20 matches
Mail list logo
