Miha
What comes to mind reading your reply, as a long time user of tiddlywiki, I
do not experience the issues of mixed wikitext and code, in some ways I
already have a "blocks" based solution.
I have no problem transfering text from one wiki to another or a seperate
system. This is all with vanila tiddlywiki, and it is only a matter of my
"practices", nothing else.
To achieve what you and others are suggesting can rest on this prior work
already built in to achieve the results faster.
I will state them succinctly and you can ask for more info as needed.
- I tend to keep Real text in standard tiddlers with all code in
$:/systemTiddlers, macros or view templates use these.
- I tend to use a view template to display, often conditionally, the
content of any standard tiddler, this view template will invoke macros
etc... as needed to display the fields and other value. ie they are not
placed in the wiki text except in limited circumstances.
- Many of my tiddler have no text field, this is simply retained for
additional notes, all the results come from how the tiddler is tagged or
fields it contains, tags are used to get information from elsewhere in the
wiki.
- Tiddlers are my blocks, and the view template assembles them
- Given this method I can introduce drag and drop reordering if an when
desired.
- I will use the occasional class or macros in my wikitext but they are
usually meaningful to the reader and do not distract from the notes.
- If transferring content from a TiddlyWiki to another location I do not
copy the wikitex,t they can't process, I use the following methods
- Copy and paste the rendered output
- Print to a text file
- Print to a PDF
- Copy the resulting html
- sometimes paste the copied html as plain text
- Generate csv formatted text I copy and paste
In the editor there is a preview mechanism, additional preview formats can
be used out of the box or even developed. I use the HTML one to extract
HTML snipits for use elsewhere, For example we could have a parser that
provided a "preview" that instead of presenting html, presented raw
markdown. If you can see something in preview its trival to provide copy to
clipboard, export or even drag and drop to move content in another format.
I am not sure but when you refer to *Abstract Syntax Tree (AST) * I think
it may already exist. Its the Widget Tree, Install the plugin "Tools for
exploring the internals of TiddlyWiki", and edit a complex tiddler, select
the preview and the Widget Tree Option.
An important point with tiddlywiki is it has a sophisticated set of
mechanisms that allow changes to be reflected through out your wiki almost
instantainiously, this is also very efficient because it knows how to
refresh only what it must refresh, in part by acting only on what is
visible.
A lot can be built on top of tiddlywiki without the deeper knowledge,
however if looking to revolutionary changes you will often discover the
underlying mechanisms already exist. The only cost being understanding and
making use of these powerful methods. For example the introduction of
javascript needs to follow the rule that maintain this instantaniouse
update model.
Regards
Tony
On Thursday, 30 April 2020 11:10:32 UTC+10, Miha Lunar wrote:
>
> Hi Edgaras and others! This is a great initiative!
>
> I really like these ideas and the minimalistic mockups look really nice.
> Before finding TW I was using Notion for a while and I think it has a
> really neat UX that's complex under the hood, but presented nicely.
>
> Re: mixing wikitext and Markdown: They are fundamentally incompatible in
> some areas, e.g. # in MD means header, while in WT it's an ordered list
> item. Initially I also wanted to just use Markdown, but nowadays I feel
> like wikitext might actually be "the better Markdown". That's bad because
> then it's harder to champion for the more mainstream Markdown :)
>
> Re: modeless editing: I feel like this is a really powerful concept that
> brought text and layout editing to the masses. At the same time, I believe
> having an editable readable text "source" for a document is powerful in
> terms of:
> • reproducibility - you can copy paste a section of the source to someone
> and they will get the same thing barring side effects
> • consistency - all the state is visible, so it's harder to get into a
> weird state where some hidden format or layout is affecting your writing
> unintentionally
> • flexibility - since code is usually text too, you can essentially have a
> way more flexible system if you can also write "code" within text (wikitext
> has this with transclusions, etc., LaTeX too)
>
> That said, as you mentioned, looking at / parsing all this additional code
> all the time can be taxing, as as much as we want them to be, human brains
> aren't really great computer grammar parsers :)
>
> This brings me to what you and others mentioned and what I believe Notion
> got really right. The concept of logical blocks a page / note consists of.
> This can be a paragraph, a link, an image, a table, etc. In Notion it's
> natural to add these, you type a / and up pops a small non-intrusive
> command search popup, where you just search for a thing to add.
>
> These quick-add slash commands would be essential when it comes to the
> unified view / edit flow imo. On top of that add drag and drop reordering
> logic and you're 80% there.
>
> So how do you reconcile having source editing and Notion-like blocks? I
> would start by keeping the source and having a special type of a UI view
> that is smart enough to modify the source directly through UI actions like
> typing in the middle of some text, adding a new block (read: header, image,
> tiddler link, transclusion, anything that's a toolbar button right now)
> with a slash command, or reordering some blocks in the tiddler (e.g.
> dragging a header a few paragraphs higher would move it in source text a
> few lines up).
>
> Now for a little nerd talk. Jeremy, I hope you're listening ☺
>
> Technically, this would have to be done carefully as to not corrupt or
> change the source in any unexpected way. The complexity depends a little on
> how wikitext is parsed currently. If it's the standard lexer-parser setup
> where you get an Abstract Syntax Tree (AST) somewhere in the middle before
> you convert it into HTML it would already help a lot.
>
> One interesting feature that many parsers usually don't care about is that
> we would need is for the AST to be losslessly reversible back into wikitext
> (including whitespace, comments, everything). That way we would be able to
> operate on the source in a safe and structured manner without losing any
> extra stuff in it.
>
> To be able to visually link the blocks back to their source text, we would
> need to track all the up-to-date character ranges for the parsed tokens /
> AST leaves and carry their ids up to the UI / HTML elements used to display
> them. Then when you e.g. have a list of images and you drag an image, the
> UI knows of the hierarchy behind the display (from the AST) and at the same
> time knows how to modify the source text (by the character ranges in each
> AST element) to produce the desired modified output.
>
> Nerd mode off.
>
> Clearly you won't have a UI that allows you to edit every single wikitext
> feature including transclusions, macros, etc. on day one. But I see great
> value in having even just bold, italic, headers and links as an MVP and
> blackboxing everything that is not supported. Since the source wikitext
> would remain, you could always switch to the source view for more advanced
> stuff.
>
> Now if we entertain this modeless direct editing experience some more, I
> can imagine all the blackboxed blocks turning into inline source code
> editors. Transclusions could provide a way for editing the source tiddler
> directly by showing a nested UI in the context of the transcluded tiddler
> with some border or whatever showing up to tell you which one it is.
>
> I'm not saying it would be easy, but it's definitely achievable,
> especially if you limit the scope of what to do initially. :)
>
> Welp, I spent too much time writing this brain dump, so I hope it gave
> some ideas to someone at least. :)
>
> Best,
> Miha
>
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/be88ada0-dd23-4cdd-bea0-a62040ccaf13%40googlegroups.com.
