Wysiwyg editor roadblock

[Stephen Kimmel]

Folks,

I’ve started work on a TiddlyWiki native wysiwyg editor. Although I still have a long way to go before I’ll have anything stable enough to unleash on the general public, I thought it might worthwhile to solicit input from the group as a whole. What do you think a wysiwyg editor for Tiddlywiki ought to look like? How should it act? That sort of thing. And I’ve hit a roadblock that may make the entire exercise academic. Perhaps someone in the group has an insight that could help me get around this difficulty.

First though, allow me to describe how I see the project and where I stand. I see this project as a plugin rather than something that displaces a major portion of the program. One result of that is the idea that I will disrupt the normal operation of the program as little as possible. At the moment, my prototype has the ordinary text editor panel on the left and makes the preview panel on the right an editable panel. Like the standard Tiddlywiki, this is a two state arrangement with either the text editor alone or the dual panel arrangement. I see the end product having a three state arrangement; text editor alone, wysiwyg editor alone or side by side.

As I understand how Tiddlywiki works, the text editor modifies the raw wikitext which is rendered into html with each change for display in the preview window by the browser. The displayed version is strictly temporary until the tiddler behind the display is saved. The actual displayed html is not saved. Editing in the preview window like I’m currently doing means I’m editing the displayed html. To make the changes permanent, I have to convert the displayed html into wikitext. I’ve taken to referring to this process as derendering. (I know. It’s an ugly excuse for a word but I’ve grown to like it.)

As the project stands now, I can make most of the standard text editing functions (bold, underline, italics, highlighting, lists and such) work in the preview window and derender them back into wikitext. The routine is glitchy and there are some aspects like images that do not act the way I want them to work.

And now the roadblock. Wikitext is not just the contents but also a set of assembly instructions. A good example, and the heart of my problem, is transclusion. When one tiddler is transcluded into another for the display, its contents are merged into the tiddler being displayed without any indication of its origin. In the displayed html, it is simply more text. When the program derenders that the result is the wikitext for the original tiddler and the transcluded one without any hint of the transclusion and so the transclude command is lost. This sort of thing happens with several of the twiddlywiki features like automatic lists, etc. This effect is unacceptable as it does massive damage to the core concept of Tiddlywiki.

My best idea on how to fix the problem requires Tiddlywiki to handle transclusions slightly differently and as a result requires modifications deeper and more fundamental to the code than I’m comfortable making. Specifically, my idea is to make the html that results from the transclusion look something like this: 

Here is some text from the “outside” tiddler

<!—{{transcludedTiddler}} -->
 
This is the transcluded tiddler inside the other tiddler
 
<!—end transclusion -->

Here is some more text from the “outside” tiddler

By using comments I don’t introduce any new HTML elements to confuse the system but I do have the information I need to reconstruct the transclusion command correctly in wikitext. To make Tiddlywiki do something like this is beyond my comfort level so I can’t say I’m very happy with this answer.

Does someone have a better idea?

[Mat]

>When one tiddler is transcluded into another for the display, its contents are merged into the tiddler being displayed without any indication of its origin. [...] ...This sort of thing happens with several of the twiddlywiki features like automatic lists, etc.

I'm not qualified to answer your questions, but in reading the above it strikes me that IF such a fundamental thing like transclusions is redesigned, then this may be an opportunity to also consider potential needs for "the coming federation" including needs for e.g "remote transclusion". It is reasonable to expect a generally greater need to trace things in a federated network than currently. 

>This effect is unacceptable as it does massive damage to the core concept of Tiddlywiki. 

What do you actually mean with "core concept" here?

<:-)

[Stephen Kimmel]

>This effect is unacceptable as it does massive damage to the core concept of Tiddlywiki. 

What do you actually mean with "core concept" here?

A fundamental concept of TiddlyWiki is that it works with small pieces of information, ie Tiddlers, which can be easily rearranged and regrouped as desired either in the Tiddlers shown on the screen at any given moment or transcluded into what looks like a Tiddler. A routine that eliminates the temporary nature of transclusion and makes it permanent is almost the exact opposite of that understanding. That's what I meant.

[Jeremy Ruston]

Hi Steve

Great stuff, very pleased you are have been making progress.

> And now the roadblock. Wikitext is not just the contents but also a set of assembly instructions. A good example, and the heart of my problem, is transclusion. When one tiddler is transcluded into another for the display, its contents are merged into the tiddler being displayed without any indication of its origin. In the displayed html, it is simply more text. When the program derenders that the result is the wikitext for the original tiddler and the transcluded one without any hint of the transclusion and so the transclude command is lost. This sort of thing happens with several of the twiddlywiki features like automatic lists, etc. This effect is unacceptable as it does massive damage to the core concept of Tiddlywiki. 

Intentionally, transclusion (and other widgets) do not have to emit DOM nodes. This is necessary because in many situations HTML is very specific about element nesting. For example, the <select> element requires that its <option> elements are immediate children. If transclusion always produced, say, a <div> element describing the transclusion, then it would be impossible to transclude the <option> elements.

> My best idea on how to fix the problem requires Tiddlywiki to handle transclusions slightly differently and as a result requires modifications deeper and more fundamental to the code than I’m comfortable making. Specifically, my idea is to make the html that results from the transclusion look something like this:  

Unfortunately, this would represent a major backwards compatibility break.

However, I do think that there is a workable approach.

The key is to understand how TiddlyWiki internally processes wikitext into the DOM. There are three steps.

First, the wikitext is parsed into a tree that represents it's structure. You can see a parse tree in the developer console like this:

$tw.wiki.parseTiddler("HelloThere").tree

Depending on your browser, it may be clearer to look at the formatted JSON representation:

JSON.stringify($tw.wiki.parseTiddler("HelloThere").tree,null,4)

Secondly, the parse tree is rendered into the widget tree. The widget tree is built up from the root widget object which you can see with:

$tw.rootWidget

Thirdly, each widget renders and updates DOM nodes as required.

I believe that the best approach for a WYSIWYG editor is to display a formatted version of the parse tree within a contenteditable DIV. The parse tree includes widgets like <$transclude>, which you may want to render in a special way, with click handlers to allow popup editing. You'd also render most HTML elements normally (eg, ul/li, bold etc).

I've got some code that does some of what is required: an unfinished parse-tree widget that's intended to render a "pretty" version of the parse tree corresponding to a specified tiddler. If I push the branch to GitHub would you be able to use Node.js to build yourself an HTML file from it?

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/7059d3fc-bc59-43df-adec-17e34a21dcd3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jeremy Ruston
mailto:jeremy...@gmail.com

[Danielo Rodríguez]

Sorry for the offtopic but, Jeremy, regarding this:

Secondly, the parse tree is rendered into the widget tree.

With rendered I understand that it is parsed and converted to its final state. Like rendering a movie from the cgi. Is that what you intend to say? Or is it just pushed into the widget tree? Because if it is rendered it loses its interactivity.


Coming back to the topic, is there any link to test this out?

[Stephen Kimmel]

I've got some code that does some of what is required: an unfinished parse-tree widget that's intended to render a "pretty" version of the parse tree corresponding to a specified tiddler. If I push the branch to GitHub would you be able to use Node.js to build yourself an HTML file from it?

It would require mastering Node.js (so far everything I've done has been in browser... typically Firefox or Chrome) and GitHub (at least enough to know what you mean by "push the branch")... but I'm probably overdue to take on those tasks anyway.  Absent those accomplishments, no.

Go ahead and "push the branch" and let me take a shot at it.

[Stephen Kimmel]

Jeremy,

Go ahead and "push the branch" and let me take a shot at it.

Perhaps its a demonstration of my ignorance but... have you pushed the branch and is there some easy way for me to know when and where it is?

[Jeremy Ruston]

Hi Steve

Apologies, I've only just had a chance to look at this.

I've pushed the new branch here:

https://github.com/Jermolene/TiddlyWiki5/tree/parse-tree-widget

You can see the changes from the current master branch here:

https://github.com/Jermolene/TiddlyWiki5/compare/parse-tree-widget

And I've pushed a build to TiddlySpot:

http://tw5test.tiddlyspot.com/

The part I'm drawing your attention to is the parse-tree widget. It renders the parse tree of a tiddler into the DOM as an outline; I'm suggesting that you render the parse tree in a more WYSIWYG fashion, and set the result to contenteditable.

https://github.com/Jermolene/TiddlyWiki5/blob/parse-tree-widget/core/modules/widgets/parse-tree.js

Best wishes

Jeremy.

 

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/8dd0169d-a54a-4638-b751-91ddb3f8c141%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.