@Mat > IF these changes are also supposed to deal with the move-with-arrow-keys > issue, then that aspect does not seem to work fully yet. But, yes, it does > show the popup and I'll continue with the wikitext. > >
My changes today are meant solely to address the missing selectionEnd variable after we moved the trigger code from the _Popup tiddler to the editor tiddler. The refactoring changes you are making, open the door to solving the move-with-arrow-keys issue. If you look at my description from earlier of the proposed flow after refactoring (reproduced below), we haven't yet implemented the part in yellow. However, we now have that possibility. This might require JS or it might be as simple as deleting the state tiddler. *Instead I propose we refactor our code for the following flow* (note this > is all wikitext changes we are discussing here): > > - User types in *edit* widget > > > - for *every keystroke* edit widget invokes *actions* > > > - in these actions in *$:/core/ui/EditTemplate/body/editor* we have > our wikitext code from EditorMagic/_Popup which checks IF there is a > trigger-start that should prompt the showing of a popup. > > > - Only *if* there is a match, do we invoke action-popup-caret. > > > - We can also save extra information to the state tiddler, like what > text triggered the match, what kind of popup to show (link, widget etc) > > > - If there is no match, we cancel any already shown popups. > > > - When the popup is shown, it reads info from the state tiddler to > determine what content to show. All the wikitext related to WHAT to show > stays here. > > (My *first *tests indicate I must keep the trigger controls etc in _Popup > anyway, making for such checks both there and around the > $action-popupcaret.) A possible approach here is to save the detected fragment, and the type of autocompletion in the state tiddler and read it from there in the popup. Then the popup just needs to display the appropriate content. The code around $action-popupcaret would handle detection, the code in the popup would handle display. Example pseudocode: <$action-popupcaret $state=<<qualify $:/state/EditorMagicPopupState>>/> <$action-setfield $tiddler=<<qualify $:/state/EditorMagic/PopupState>> em-fragment=<<fragment>> em-triggerType=<<triggerType>>/> An explanation of how to set a variable available in the popup, from the state tiddler, is provided earlier in the thread. Either you need to extend trigger definitions with a "type", eg widget, links etc. Or, be able to use the <<trigger>> (<< or <$ etc) for the purpose of knowing what display logic to use. So in the popup: triggerType is "link" -> transclude tiddler for links, which displays links that match "fragment" or triggerType is "widget" -> transclude tiddler for widgets, which displays links that match "fragment" or trigger is "<$" -> transclude tiddler for widgets.... This is all pseudocode and talking off the top of my head, so don't take it too literally. I hope it serves as an example of how to convey information to the popup and avoid having the detection code in two places. > I wonder if it would make things easier if you used a TW file hosted on >> github with the git saver, so I could easily see what had changed in each >> file. I haven't used the git saver but it should in theory be as easy as >> using tiddlyspot. >> > > I have not used it either. I'll do a quick investigation but given my > failing adventures with gh at large, I kind of doubt it will be as simple > to use as tiddlyspot. > I would hope its as simple as, set up a github repo to use github pages, upload file via web interface. Then load it via web URL and save as you would on tiddlyspot. 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/f5b3bd9e-93b4-4d45-92ad-a15461273fb1o%40googlegroups.com.
