Hi Mat,
> 1. Pop up position: Creating a new row seems to take presedence and > steer where the popups shows. I get this bug(?) to most consistently show > if the text *starts out* with empty rows, then the popup shows in that > area rather than where the title is completed. > > Could you post a screenshot and/or precise steps to recreate this? I am not quite sure I follow. I wonder if its related to the item below, popup position not updating once it has been shown. > > 1. I can't find it in this thread now but I think you mentioned that: > The popup doesn't follow the caret if it is moved using the keyboard arrows > and then typing. > > Yes. Basically under the covers, the first popup is never dismissed until and unless you click somewhere, and when it's shown again, the old position is used because of the way the core handles popups. We could try to patch this now, but I think there is a better way to control triggering the popup which would also handle this issue. So I suggest we live this for now if it's not a deal breaker. If you don't first trigger a popup and without autocompleting a title, move the caret around with the keyboard, the position should be correct. Try this: Open the tiddler *$:/plugins/EditorMagic/reveal-widget-tweak* and give it a *module-type* field with value *startup*. Restart and test again. This is one approach to address the above issue but has other side effects I don't like (which could also be fixed)... anyway there are lots of ways to solve this problem. I think waiting a bit to see how everything else develops will let us choose the best one. > 1. If the text already has the closing brackets, e.g [[bar]] and you > stand just to the right of the "r" and pick e.g title "barbaz", then you > get [[barbaz]]]] - i.e if there's a closing "]]" they should probably be > removed at injection. > > Yeah I noticed this too. To be honest, I have experienced similar behaviours in other text editors that do similar things, so I feel like it isn't a huge problem. Autocompleting a link vs updating an existing link are after all different things. That said, this is all handled in wikitext. So you could check the portion of the text after the caret, to make sure it doesn't start with the end part of the trigger. If it does, remove those characters. But how do you make sure that isn't somehow useful user text you are stripping out? :) > > 1. Possibly not relevant at this moment: After the injection, it is > desirable that focus - i.e the caret - is returned to where the text was > just inserted. Currently one has to click to insert caret. > > I think using the tm-edit-text-operation approach we could address this. The core otherwise doesn't have any facilities for remembering/restoring the caret position. 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/CAJuiAb26RR_4nm0LNzrFbBu5Y-FvBPYXDAGgqoKQDMamn%3D%3DksA%40mail.gmail.com.
