Hi Evan,
I like the general capability to import from csv genericaly.
Here's how I would think the process makes most sense:
1. you drag a csv into the wiki
2. the import then creates a tiddler from the overall csv whereas
1. *text*: corresponds to the csv body
2. *title*:
Hey, Jeremy —
OK, good to know this stuff is on your radar. For the time being, my
plugin is functional (just less convenient than it could be).
My inclination would be to stand by for any future developments in
TiddlyWiki's import workflow, and jump in and upgrade the plugin if and
when
Hi Evan
> I'm working on this CSV "unpacker" plugin:
> http://evanbalster.com/tiddlywiki/csv_unpack.html
Good stuff.
> The introduction of deserializer modules, which I only discovered half-way
> through the process, made things a lot easier. But I'm a bit troubled at the
> lack of a good
I just started looking at importing CSVs as well, to use with my
RenderTable plugin. I will check out your code. Following with interest. :)
Best,
Joshua Fontany
On Wednesday, December 20, 2017 at 11:16:45 AM UTC-8, Evan Balster wrote:
>
> Hey, all —
>
> I'm working on this CSV "unpacker"
Hey, all —
I'm working on this CSV "unpacker" plugin:
http://evanbalster.com/tiddlywiki/csv_unpack.html
The introduction of deserializer modules, which I only discovered half-way
through the process, made things a lot easier. But I'm a bit troubled at
the lack of a good mechanism for
Hey, Tobias —
I fear we will just delay the parsing error ...to the next closing tag
> which now operates as a new opening tag.
>
> So, with...
>
> ''foo //bar'' baz// mumble and then some //more italics// but is it really?
>
> ...what happens if we forcefully close the italics at the second '',
Ciao Evan, Jeremy & Tobias
Jeremy Ruston wrote:
>
> An alternative that I have seen in other markup implementations is to
> treat line break as closing all open inline formatting elements.
>
Right. That behaviour is what I have see too. I suspect that's because the
simpler versions parse only
Hi Evan,
> Aside from being spooky-unintuitive, the issues here can get quite severe
> when editing complex widget code or upper sections of a long article, with
> deletrious effects on browser performance. I've seen browser lockups when
> editing widget trees with fragmentary HTML. For
At second thought,
In my last examples, the server state tiddlers accompanying a tiddler
should be relative to the user, so:
title: $:/state/server/FOO/JonDoe/AnyTiddler
instead of just
title: $:/state/server/FOO/AnyTiddler
best -tb
On Monday, 18 December 2017 14:32:12 UTC+1, Tobias Beer
Hi Evan
I agree that this is a troublesome problem, and I’d also be interested in
exploring fixes.
I think that the approach you are suggesting is for the parser to check for the
closure of parent components within a particular component; in your example,
the second pair of double single
10 matches
Mail list logo
