Hi Scott, пятница, 16 августа 2013 г., 8:28:15 UTC+4 пользователь Scott Simmons написал: > > Thanks. I hope that this year it will become about 50% more cool again :) >> reloading is on its way, and some other features as well, but the >> development doesn't go very fast.. may be I even have to redesign some >> internals once again. >> > > Slow and steady wins the race. ;) It's certainly taken me long enough to > catch up to you as a user, and I don't mind waiting for updates, especially > when the current version suits my needs so well. > > >> Ok, I can see where the problem can be from. Try this: grab the full-code >> version of STP [1] and substitute the line >> >> includeURL = w.tiddler.getIncludeURL(), >> >> with the line >> >> includeURL = w.tiddler ? w.tiddler.getIncludeURL() : "", >> >> and let me know the result. Or you can send me a TW you have trouble with >> to me directly. >> > > That worked beautifully for me at first -- >
Ok, this fix will be included in the next release. > until I had multiple TWs with SharedTiddlersPlugin enabled open at the > same time. > As you point that the new alert pops only with ImageFormatter hijacking, the new thing shouldn't be connected with the previous one. > When that occurs, I get a slightly different alert: > > > <http://tiddlywiki.secret-hq.com/images/screenshots/TiddlyWiki%20SharedTiddlersPlugin%20errors/search_PrettyLinkHijackWithNodeError.png> > > The alert mention the "search" method; only two functinos in STP use it "explicitly": stp_resolveURL and isRelativeURL, but I don't see those being used in the hijacking. It would be helpful if you try to debug this by adding try { <stuff with "url.search" part> } catch(e) { alert(<smth>); } blocks in those two functions -- this will let us know whether the exceptions occur in those functions or in some code from "outside" of the plugin. Again, if you attach minimal test TW files to reproduce the problem, I can try to track it myself. > I may have introduced a new bug on my end. To manage > config.options.STP_hijackPrettyLink and > config.options.STP_hijackImageFormatter, I created two option checkboxes -- > chkLetSTPHijackPrettyLinks and chkLetSTPHijackImageFormatter, > respectively. Then I check and set the main values with this line before > your code: > > config.options.STP_hijackPrettyLink = > config.options.chkLetSTPHijackPrettyLinks;config.options.STP_hijackImageFormatter > = config.options.chkLetSTPHijackImageFormatter; > > > (The idea was to insulate your values from my cookies so I could turn off > or delete my cookies if you used something different later on. Of course, > that introduces the possibility that I've screwed something up.) > > Maybe there's a conflict somewhere between the cookies being set by these > options? > > I wouldn't expect any problems merely because of cookies: the config.options.STP_... parameters are only used at startup, so no big deal if they are set randomly. The null/"" difference should actually make no difference in PrettyLink hijack, too: both versions lead to the same result in includeURL? includeURL : undefined part and includeURL is not used anywhere else in the function.. > I'll try overriding them by hard-coding the values for > config.options.STP_hijackPrettyLink and > config.options.STP_hijackImageFormatter and report back. (But if anyone > spots anything bone-headed about my scheme itself, please chime in and let > me know.) > > >> As for the trouble with the [[tiddler]]@node syntax, I didn't really get >> what happens/doesn't happen. May be you can attach a couple of TWs with >> minimum tiddlers reproducing the problem? >> (describeNode macro can be used inline, but I consider that as rather bad >> practice -- it was introduced in first place to be able to use one nodeName >> in several places, so the definition should be elsewhere, in IncludeList) >> > > In putting together a test case to show you, I saw the problem. It wasn't > my syntax -- but it was some ham-fisted TiddlyWiking on my part. :( > > My inline node definition was enclosed in /% and %/ as part of the > definitions of a tab set. E.g.: > > <<tabs txtTabSetTabs "tab1" "first tab" [[ThisTiddler##MyTab]] etc.>> > /% > !MyTab > > <<describeNode "nodeName" "index.html">>See [[this > link|ThatTiddler]]@nodeName for details. > %/ > > ... which is why I was seeing the error: The node definition wasn't being > set because it was hidden from display and wikification! (When the section > it was contained within was displayed in the tab set, the link and text got > wikified fine, but the node definition doesn't get wikified in that context > and was undefined. (Hence the error.) > > Of course, this is handily avoided by defining all nodes in IncludeList. :P > Right, so no real problem here. By the way, you can use css to hide inline describeNode macros, but again, that's not how they are intended to be used (so I don't add any "hide" options to them). I've took a look at your "re-written documentation", perhaps I'll use more tabs in the main documentation, too. At least somewhere "basic/advanced" tabs look quite appropriate. Though, those may complicate the structure of the tiddler code too much. I'll see. Best regards, Yakov. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/groups/opt_out.
