✅ Deserializing a tiddler: I can't find the position in the code where I have access to the original content of the pre-tag or the text of the tiddler in draft/edit-mode.

[Cd.K]

Hi,

I'm trying to find the location in TiddlyWiki where the white space characters are removed from the HTML <pre> tag.

So far I found this function while debugging:

$tw.Wiki.prototype.deserializeTiddlers

 

The following tiddler "period rule" has 2 space characters after the second "test":

(windows 10; firefox; TiddlyWiki 5.1.21-prerelease empty with plugins: CodeMirror Editor with all AddOns, Mod-Loader, (my) linebreak in paragraph; default tiddler: "[[period rule]]")

I set up the firefox debugger, reloaded/refreshed the TiddlyWiki and stopped in the deserializer (store Area) when calling $tw.utils.htmlDecode(e.innerHTML) for the tiddler in question:

But here one space is missing. But this space is definitely present in the HTML file and also in the tiddler in draft/edit-mode.

Either e does not contain the correct DOM node here, namely the pre-tag, or it happens even earlier in the code.

Can someone help me out here?

Regards

Cd.K

[Jeremy Ruston]

Hi CdK

I'm trying to find the location in TiddlyWiki where the white space characters are removed from the HTML <pre> tag. This happens before parsing. 

I’m not sure what you mean. Can you show an example of spaces being removed that works on tiddlywiki.com?

So far I found this function while debugging:

$tw.Wiki.prototype.deserializeTiddlers`.

deserializeTiddlers is used to extract tiddler data from the store area DIV during startup.

The following tiddler "period rule" has 2 space characters after the second "test":

(windows 10, firefox, TiddlyWiki 5.1.21-prerelease empty with plugins: CodeMirror Editor with all AddOns, Mod-Loader Plugin, (my) linebreak in  paragraph, default tiddler: "[[period rule]]")

I set up the firefox debugger, reloaded/refreshed the TiddlyWiki and stopped in the deserializer (store Area) when calling $tw.utils.htmlDecode(e.innerHTML) for the tiddler in question:

But here one space is missing. But this space is definitely present in the HTML file and also in the tiddler in draft/edit-mode.

Either e does not contain the correct DOM node here, namely the pre-tag, or it happens even earlier in the code.

Are you saying that the text for a tiddler that you are seeing in the HTML file doesn’t match the text you see within TW?

Best wishes

Jeremy

Can someone help me out here?

Regards

Cd.K

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/ac6eac1f-9752-46b8-b0e4-0f34c2bf48c5%40googlegroups.com.

[Cd.K]

Hello Jeremy Ruston

 

Are you saying that the text for a tiddler that you are seeing in the HTML file doesn’t match the text you see within TW?

 

No, I don't. It's not about a mistake.

I just want to know where to set a breakpoint in the debugger to see the original content of the tiddler's text field.

Perhaps the following example with 10 spaces is clearer:

number of blanks
between prefix
and suffix: 10
prefix          suffix

Tiddler:

rendered with one blank between "prefix" and "suffix".

Tiddler in draft mode:

You can see all 10 blanks between "prefix" and "suffix". 

How can I display these 10 spaces in the debugger? Which function or method do I have to debug? 

What I'm actually interested in: Is there a function that returns the original ("draft") content of the tiddler's text field for a given tiddler title? Or which functions/methods do I have to use to build such a function?  

Regards

Cd.K

[Cd.K]

Hello Jeremy Ruston

The problem is that the firefox debugger does not correctly display a string variable in the debugger panel.

I found this out with a breakpoint in $:/core/modules/editor/engines/framed.js when passing the tiddler text to the editor:

The tiddler's text field is not rendered yet.

And here the value of the text in the debugger panel: Without consecutive blanks.

Step over F10 or Step in F11  => text is rendered (with consecutive blanks)

And the result of the log breakpoint

 
`Cd.K this.domNode.value = ${this.domNode.value}`

in the Console panel:

10 blanks between "prefix" and "suffix"!

I filed a bug report (#1584879) .

Regards

Cd.K

[Jeremy Ruston]

Hi Cd.K.

I think maybe you're running into the way that HTML coalesces adjacent whitespace by default. The process is actually controlled by CSS -- see the CSS white-space property:

https://developer.mozilla.org/en/docs/Web/CSS/white-space

Generally, TW5 wikitext passes whitespace through to the browser's HTML parser.

Best wishes

Jeremy

[@TiddlyTweeter]

My limited observations ...

Clarity about parsers is good.

They are really useful to know more about.

As far as I grasp it many parsers use regex (within a basic AST). 

Two issues I saw ...

(1) what occurs if a para/line has no WikiText markup?

(2) what browsers do nomally with whitespace.

My two cents.

TT 

[coda coder]

Hi Cd.K

I hope you'll take Jeremy's word for it - he's telling you the same as I told you (same link too). Browsers have been collapsing white-space for over 25 years - even before there was any CSS.

You space-space idea seems like you're trying to "fudge" a little bit of markdown into HTML. Like I said before, that's going to break things - long standing things.

As for your bug report: good luck, but don't hold your breath. You might want to see a similar one I filed six years ago that went absolutely nowhere (well, they did eventually add my "small black box" idea).

https://bugzilla.mozilla.org/show_bug.cgi?id=967493

Fact is, once the HTML is rendered, they've lost it. All they have is the DOM. Sounds crazy, but that's the net effect. Even crazier, if you right-click, Edit as HTML, all is revealed. Talk about lunacy...

[TonyM]

C dK

Could you restate what you end objective is once again!

There may be other approaches to achieve the same thing.

Perhaps in a new Tiddlywiki forum thread.

Regards

Tony

[Cd.K]

Hi coda coder && TonyM

The "blanks-rule" rule is also over 15 years old. I think it is elegant, visually unobtrusive and does not interfere with the writing flow. And I already use it here: TiddlyWiki-DocsWiki (github Arlen22) in association with TiddlyWiki. There you can also try it out for yourself.   

To implement it in a TiddlyWiki (markdown) plugin I need access to the raw string. Otherwise, I can't find the 2 (or more) spaces before a "\n" line break and can't trigger my rule.

I searched with the help of the debugger for my purposes suitable place in the existing code and fell flat on my face because the debugger has a problem: Variables are not displayed correctly everywhere.
If I had included console.log statements in the code, it wouldn't have happened to me. But usually, you can analyze faster if you make as few changes to the code as possible (you just save the change, the build process, and then undoing the change plus another build process) and let the debugger do as much of the work as possible. I had already found the right place and because of the debugger flaw, I couldn't perceive that I had finished my analysis and so I kept fruitless searching.

I mean, you have to be able to rely on a debugger.

It would be interesting to see how the google chrome debugger behaves at this point. 

Regards

Cd.K