@Mat replies inline Also, if you look at the Browser Developer tools console (ctrl+shift+I on >> chrome), there is some additonal debugging going on. >> > > If I interpret it correctly, that's why the iframe for WidgetDocs doesn't > work. >
There is an error logged to do with the iframe, but that's not due to anything I've changed. Mixed Content: The page at 'https://saqimtiaz.github.io/sq-tw/em3.html' was loaded over HTTPS, but requested an insecure frame 'http://tiddlywiki.com/static/ActionCreateTiddlerWidget.html'. This request has been blocked; the content must be served over HTTPS. > I'm guessing the above does not have anything to do with the fact that > typing <$ now only shows one popup content, as opposed to two contents > previously i.e both WidgetDocs and the WidgetPicker that use the same > trigger. I.e can a trigger now only trigger a single content in the popup? > (namely thei first title, alphabetically). This is not a problem (one can > modify the popup content to feature multiple things if one wants to.) > Yes, this was a necessary change to ensure that only the trigger closest to the caret triggers a popup. If 2 triggers are the same, they are equally close to the popup and can't be distinguished so the first one wins. > > About ../body/editor > > That's some pretty advanced coding now. Lots of levels - which might not > be desirable per se but I'm impressed how/that you seem to have solved it. > I don't understand how you realized you should do a recursive popping back > and forth between processM..A..T and processNext.. but well done. > It's just a recursive macro. The em-checkNextTrigger macro is just the emptyMessage from em-checkTrigger, moved to an external macro for readability. All it does is choose the next "definition" tiddler and call em-checkTrigger. Basically, a normal list widget is great when you want to perform an action for every result. That is not what we want. We want to test all definition tiddlers for matches, and at the end decide what to do. That requires a recursive macro, setting variables before calling itself again. This way the values of the variables are remembered from step to step. > ...and $action-log is that for testing? > Yes, at its simplest when it runs it logs all variables to the console in a nice table. Side note: May I ask if you use any particular tools for your dev? For one > thing, I assume you don't develop directly in TW as I do (in the > SideEditor) but I never understood how it can be effective to not see the > results directly. Or do you, somehow see the results live? > I do work with node and tiddlers as separate files. I don't really need to save and reload often, I think that's the key. Usually I can write a set of actions like the ones we are dealing with here in one go. If they don't quite work right away, there isnt much trial and error. It is more a case of analyizing the logged variables to figure out where its going wrong. > What other things can you think of that I can do? > All variables need to renamed, to have a prefix, like em-, em-detection-, em-display- The idea is both to avoid name clashes with user macros but also to make the names more self explanatory. So more descriptive names instead of "tid" or "fragment". Suggest you don't do this for the body/editor code until I am done cleaning up there. I can't comment on the popup tiddlers as I have not looked at them yet. Just noted something; typing e.g [[xxxxxx will trigger the popup (i.e the > mere artifact) in spite of no tiddler prefixed such. Is this a problem? If > it is, I'm thinking some "late" filter is needed, i.e after the mechanism > knows what type of "thing" is looked at (i.e is it a title or a macroname, > etc) ...so it if we want to keep the separation of concerns between > /body/editor and /Popup, I guess this should also go into /body/editor > somewhere... IFF this all is a problem. Yes, this is why it was difficult to ensure that we only show a popup for the last trigger before the caret. The same problem exists for widgets and macros, eg <$xxxx or <<xxxx The title picker trigger detection considers this a valid match: [[$:/themes/ <$ <<xxxxx <$accccccc" This is a basic shortcoming of the way you have designed the trigger detection. Ideally instead of a regexp just checking for say <$ you would check also for what comes after that, which character are allowed and which not. I am not sure how much flexibility the regexp implementation in TW offers us though. So this definitely isn't ideal and I did think about bringing this up while tweaking the code last night and today. Resolving this may also allow us to make the recursive multi level list code in body/editor simpler, but woul add its own complexity. It may be something we can live with, if it doesn't cause visual artifacts or performance issues. Otherwise we could consider a second regexp check for the "fragment" after the caret. I would say leave it alone for now, but be prepared to have to deal with it. I'll clean up the body/editor code sometime this weekend. Cheers, Saq -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/dd8b01db-09f6-4f88-b48f-ce7537576b23o%40googlegroups.com.
