"Discussion examples" converted into tiddlers?

Developers
#1

It would be neat if “pseudo tiddlers”, as often expressed in forum discussions, could directly be converted into real tiddlers. I.e if this text:

title: Foo
tags: $:/mytag
text:
howdy dowdy

…could be selected and dragged into a wiki - and it directly becomes a tiddler (as if a JSON tiddler)!

Do consider that this “pseudo tiddler format” is very common and that the context is typically one where one does intend for it to be converted into a real tiddler.

Is it at all possible to create some “interpreter/converter” that is flexible enough to allow such a loose format?

EDIT: I note Discourse features a “copy text” button when hovering the code. So, instead of drag’n dropping onto ones TW it could be to paste it which is even better than drag’n drop. If at all possible.

1 Like
Tiddler Discourse Plugin
This is a TEST dev-thread to test copy paste from Talk to TW and vice versa
#2

Whoah! Brilliant thought! I’m not so good on tech but maybe it could work? Neat if it could. If Discourse can’t do it directly then maybe a bookmarklet might? Just an idiot thought.

TT, x

#3

I’m thinking it is TW that should do it, i.e it happens when you drop it onto your TW just like when you drop a JSON tiddler onto it.

#4

Ah. Got it. I think? A TW import parser?

#5

Right. So the “pseudo tiddler” can be taken from anywhere and dumped into TW.

1 Like
#6

Possible? Yes. That’s a DataTiddler. The text field would need to be handled more carefully though.

#7

DataTiddler - Ha! Good observation - if it was the content of a tiddler then it would indeed be a datatiddler.

I guess some convention could be introduced such that the text: would have to be the lastly defined field in the forum post and so anything after text: is converted to be the content of the tiddlers text field. I.e if one wants customfield: then this has to be included above text:.

1 Like
#8

Or, anything not preceded by title: or tags: is considered the text field body:

title: my-tiddler
tags: stuff

Everything else here is my content
1 Like
#9

That’s the .tid file format we already use. The main problem is similar to the “copy / paste” problem of image tiddlers. The clipboard only gives us the content as a string.

So either the “dropzone widget” or the tw importer would need to handle that.

I think it has to be the importer, since it’s the only way to establish “user interaction”. Because it depends, on the user, if s/he wants to import the content as “pure text” or if it should be “interpreted” as tiddler content.

1 Like
#10

It may be possible to create a new “Convert to Tiddler” button

grafik
grafik1334×636 25.6 KB

But this would result in 2 clicks more … and … the user would need to know about this function.

A second possibility would be, to add a general possibility to convert “text/plain” tiddlers with the right format into “real tiddlers”

grafik
grafik1349×607 45 KB

Just brainstorming :wink:

1 Like
#11

This is just a test in Discourse, to see if the Copy to clipboard button gives us more possibilities.

Some test text

Edit: It seems it doesn’t :frowning:

#13

Yep. As you probably surmised, I was hoping this kind of “sparse” tiddler could be interpreted as a special datatiddler. Text following a newline, that does NOT begin with /.+\:/ gets thrown into the text field.

(That regex is too loose, of course, but you get the idea).

#14

Text below the <hr> is an example “sparse tiddler”:

title: Proposal 42
tags: discourse tiddlywiki
authorname: pmario

That’s the .tid file format we already use. The main problem is similar to the “copy / paste” problem of image tiddlers. The clipboard only gives us the content as a string.
1 Like
#15

As I wrote. That’s the existing “dot tid” format, that we use to build tiddlywiki. If you put your text into a text file and name it: test.tid, you can drag & drop import it into tiddlywiki.com

See: https://tiddlywiki.com/#TiddlerFiles

It will be correctly imported as a tiddler named: “Proposal 42” with 2 tags and a field named “authorname” and the text content.

The only problem is, that we can’t identify this format if it is copied from the clipboard into a TW, as the OP suggests. … I my other 2 posts I did a bit of brainstorming, how we could solve that problem.

#16

Thanks for taking a look at this @pmario

Is there some way to introduce a “pre-step” in the import mechanism to peek at the content before it proceeds? I.e something that reads the first row in the content and if the content from the clipboard is, for example, prefixed with title: then, by convention, it is to be interpreted as a tiddler with that title, etc? Such a peeking import mechanism “pre-step” would be a generic solution to “interpret” anything dumped from the clipboard which, I presume, would also solve the images problem…

Possibly related; I note that if I use Ctrl-C to copy some formatted text in this discourse post, e.g this bold text, I can in the discourse editor paste it and it will look like this this **bold** text, i.e it retains the markup! In other words, the clipboard content evidently carries the markup somehow! But if I paste the same clipboard content into a TW editor, the markup disappears. I imagine the aforementioned “pre-step” could enable peeking at content and decide if such formatting should be retained. Just a hunch, maybe I’m wrong.

As you imply, even if they could work they’re not quite “spot on”. But good food for brainstorming.

1 Like
#17

As I wrote. The import mechanism can provide a UI, that let’s the user decide what to do with the content.

So yes. It is possible to parse the content and convert it to a tiddler if the user wants that.

#18

Yes. Sometimes that’s a nice feature and sometimes it’s really annoying. eg: for external links. … Most of the times I don’t want to copy them over into my reply.

So I do have a “love and hate” relation with that feature, that is built into the Discourse app. I’m pretty sure, they keep an internal state somewhere in the app. TW doesn’t have that info.

That’s the same thing when we do copy a tag-pill from one TW to an other TW. It’s including the tiddler payload.

If you drag and drop a tag-pill from TW to Discourse you will only get the title list and no content. … Same restriction. Discourse doesn’t know it.

#19

You can set up a custom dropzone that will correctly interpret pasted text that is in .tid format.

TiddlyWiki has a concept of modules called deserializers that allows it to understand different formats. A custom dropzone as mentioned above can be configured to use a specific deserializer. There is a long term vision of a refactor of the import mechanism to be a two step process, where the user can change/choose which deseralizer is used to interpret the imported data. This however will require a complete rewrite of the import mechanism and is therefore some ways off.

1 Like
#20

@pmario and @saqimtiaz - thanks for your input

So is the idea that the user has to use the UI (marios description) or change/choose deserializer (saq) then?
Two aspects:

It would be desirable that the user does not have to change/choose deserializer but instead that he/she can change/choose deserializer. I.e the mechanism autonomously detects the content type - e.g if the content string is prefixed with title: then it defaults to assume it is a “Discussion example tiddler” as per this OP.

The generic deluxe version would be a customizable such detection, so the user can define “if the content has attributes X then perform custom actions Y”. For example: If my clipboard dump is prefixed “meeting notes” then then my actions are executed that chop up the content into a table" - or - “If my content is of .mp3 file type then the tiddler is tagged music”, etc.)

#21

What I posted is a very high level summary of ideas around refactoring the import mechanism. I would not read much into it in terms of exact steps or UI/UX. There are a lot of thoughts and ideas in those areas which need consideration and in time will be summarized as a Github issue before eventual work on this.

1 Like