An "errors and warnings" display for tiddlers?

114 views
Skip to first unread message

Evan Balster

unread,
Jan 18, 2018, 2:20:09 PM1/18/18
to TiddlyWikiDev
Hey, all —

I've been thinking recently about how TiddlyWiki could benefit from something like the "errors and warnings" list provided by a compiler.  When displayed or previewed, the tiddler would display a small "problems" badge that could be expanded to display an accumulated list of any problems detected in the course of parsing, execution and rendering.  This would help with a number of situations where TiddlyWiki simply doesn't do what is expected.

At a baseline this could be a very simple listing of each error message, paired with a line number indicating where the originating widget lies.  Some kind of "catcher" widget enclosing the tiddler could accumulate these messages as they're generated.  Other widgets like transclude and macrocall could catch and modify the messages to note any indirections in their origin.  But bells and whistles aren't really necessary in the short term — just a way to see the information in the first place.  Improvements can be made gradually.

I'm mainly thinking about this because it's becoming increasingly apparent I need a better way to indicate various errors in formula computation, which is often used to generate attribute values or placed inside SVGs (making any error text output invisible).


As a sidenote, this mechanism might be useful for implementing refresh integrity checks.  When those diagnostics are active, any discrepancy in the refresh could be noted as a critical error.

BJ

unread,
Jan 19, 2018, 3:12:28 AM1/19/18
to TiddlyWikiDev
Another possibility would be to have an error log tiddler - this would be a temp tiddler - not saved, to stop it becoming large. All widgets and js macros could write to this tiddler, it could even be a 'virtual' tiddler, not stored in the store but connected to $tw - this would be for performance reasons.

PMario

unread,
Jan 19, 2018, 5:59:19 AM1/19/18
to TiddlyWikiDev
Hi,

TW has a logging mechanism, that reports to console.log. ... It needs to work in the browser and as a stand alone component in node js.

Have a closer look at the source. Search for $tw.utils.log or at utils.js export.log().

For my stalled beaker-adaptor, I did extend the mechanism a little bit, to make it more configurable, and write the log output to different tiddlers. ... I'll need to dig out the code, but I think, I pretty much have what the OP describes.

The biggest problem is: performance. ... If we implement a generic logging mechanism into low level functions, that are called very often, it will slow down the whole thing. ...

will post here, if I found the stuff.

have fun!
mario

Evan Balster

unread,
Jan 19, 2018, 12:55:55 PM1/19/18
to TiddlyWikiDev
Hey, all —

I feel, quite strongly, that this mechanism needs to be treated as a part of the parse and render process rather than a log, and should follow the idioms of the refresh mechanism.  I say this because I'm proposing this as a tool for users more than for developers.

What I'd like to see is a unit which is installed in the widget tree and can create a report of the following errors and warnings, which are otherwise silently ignored and can be hard to debug:
  • Parsing issues (unclosed markup and suspicious elements)
  • Attempts to transclude non-existent tiddlers
  • Attempts to expand non-existent macros
  • Unrecognized arguments in macros
  • Illegal HTML elements and attributes which have been blocked by the wiki
  • Specific errors raised by widgets and/or JavaScript macros (eg, my formula plugin's compile errors)
Ideally each warning should include a tiddler and line number, along with a "backtrace" of macro expansions and transclusions.  But again, those are bells and whistles and a warning mechanism would still be immensely useful with a fraction of this functionality.


The difficult part about implementing this is that the data needs to be maintained in a manner similar to the DOM itself, and errors may appear or disappear with each refresh.  This is complicated by the fact that certain errors only occur at parse, construction or execution time.  To remedy this I suggest accumulating warnings in a namespaced structure for each widget.  {constructErrors: ..., renderErrors: ..., refreshErrors: ...}

Another tricky problem is that it might be necessary to report errors in the page template, rather than individual tiddlers, in case of any problems rendering the main view or sidebar.  This could be accomplished by revealing another "warnings" badge with the page buttons or near the "expand" button...

coda coder

unread,
Jan 19, 2018, 5:28:17 PM1/19/18
to TiddlyWikiDev
+1

TonyM

unread,
Jan 19, 2018, 11:16:52 PM1/19/18
to TiddlyWikiDev
From the user perspective I would like an action widget That I can add on buttons etc.. where I can write something to a log Tiddler, global or <<qualify log->> so I can build an action history even on a single Tiddler and with size limits for safety.

I plan to develop a plugin something like this but if we could leverage a generic log mechanism it would save code space and allow performance focus.

Regards
Tony

Evan Balster

unread,
Jan 22, 2018, 2:53:04 PM1/22/18
to TiddlyWikiDev
Hey, Tony —

My suggestion for simple logging would be to build an "append" action, which could be made in WikiText with action-setfield and some macros, as a JavaScript macro, or as a widget similar to action-setfield.

Again, that's a different mechanism from what I have in mind for the feature described in the OP, which would be much more like IntelliSense warnings in an IDE.  (Like spell check but for code and markup instead of proper spelling and grammar.)

Jeremy Ruston

unread,
Jan 23, 2018, 3:12:37 AM1/23/18
to tiddly...@googlegroups.com
Hi Evan

There are some interesting challenges here :)

Perhaps it could be another motivation to introduce an object representing an in-progress refresh cycle which we would pass as a parameter to the refresh() method. Besides the methods and data for interacting with the list of modified tiddlers and modified attributes it could expose logging methods too.

Best wishes

--
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 https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/10155525-91c2-4613-af36-720027b0ba89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages